If it's just a matter of having an "available" console session for each site, there's no real value in the investment of an Application Server for that purpose. Those console sessions, if used, can latch onto an Application Server via the WAN.
I have been led to believe that no matter which application server you point the console at, you can still get all of the inventory data from all the other management servers. Would you say that my understanding of this is correct?
This is correct. the data is physically stored in the Management Server role. Multiple Application Servers can be configured to access one or more Management Servers, and security configurations allow you to further permit/restrict that access on a per-user basis.
Is my information also correct that any console can be directed to connect to any application server at will and it is not a 1:1 relationship with a specific application server?
Yes.
I'm not sure I follow this logic, could you please explain further? I have six geographically disparate locations that will have clients that that generate inventory data, wouldn't installing a management server in each location allow that information to be stored locally instead of being streamed across the WAN back to the data center?
Not necessarily. A Management Server is scoped to a management object. Currently for inventory purposes, the only available management objects are an Active Directory domain or a WSUS server. From a WMI-based Managed Computer Inventory perspective, all inventory for members of a single domain will be stored in a single database; there is no way to distribute this data. Ergo, unless you're inventorying a multi-domain environment, a second Management Role server would have no functional purpose.
unless each site is managed independently, it is of no advantage to install the application role in each site?
This is what I'm saying. Unless there are permanent and regular console users (plural) at a site, there's really no advantage to the overhead of having an Application Role installed.
Are there any disadvantages of installing the automation role, but not utilizing it? Does it cause a large additional (and possibly unneeded) overhead if automaton is installed, but not used?
No, there are no disadvantages. In fact, the overhead of an Automation Server is non existent except when executing actual tasks, and even then the majority of effort is sitting in wait states on an open RPC/WMI connection waiting for the client to do something.
Does Patch Manager support being installed on SQL Express 2012 or do I need to use 2008?
Patch Manager is supported on all instances/editions of SQL Server from 2005 thru 2012.
If WSUS and Patch Manager (all roles) are installed on the same box, would it be better to leave WSUS running on WID and Patch Manager under SQL Express, or should both databases be running under SQL Express?
Neither, actually. From some testing I did a long time ago, the best configuration appears to be WSUS and Patch Manager installed together using a remote SQL Server running SQL Server Standard Edition. Patch Manager installs SQL Server 2008 R2 Express Edition by default, but WSUS should not be used with Express Edition. Patch Manager cannot be used with WID. The problem with co-location becomes the competition for resources between the WID engine and the Express Edition engine. In addition, it's quite likely, even that with 1500-1800 questions, you will encounter performance issues with Patch Manager running on any version of Express Edition.
However.... there's an added variable for your environment. If you're 1800 clients are spread out over a half dozen WSUS servers, then the effective load on the local WSUS server is likely only a few hundred (or maybe even the central WSUS server has no client load at all, and all clients are using distributed WSUS servers). If this is the case, you might find the coexistence of WSUS/WID and PatchManager/SQLExpress to be tolerant.
However, the good news is that you already have Configuration Manager, which means you should already have an instance of SQL Server Standard Edition deployed. I would suggest considering migrating the WSUS database to that SQL instance (in most ConfigMgr instances the SUP database is already in the same database as the ConfigMgr Site Server), and installing Patch Manager's database to that same instance.