If you don't need to confuse your users with multiple VLANs, don't do it. Leverage the tools you have. You mentioned you have ISE and you should be able to do all this with one SSID. As AdnanG already mentioned, you can utilize the profiling features of ISE to classify the devices.
Your ACS should be able to tie into the MS AD authentication and be able to provide user authentication and group information.
From there, you just need to combine the user/groups with the device profiles and then tie it to a VLAN. So, for instance, if the device is identified as a cell phone and the user is part of "group A", then the get put in the "group A - internet" VLAN.
I haven't done it personally with ISE, so can't give exact steps, but this is how Cisco marketing is selling ISE in the BYOD space. I also know of several people who have done similar setups to what is suggested. I would start by looking through this Cisco BYOD document that would give you a general overview of how BYOD is done with with Cisco ISE.
Web authentication is really more of a means to limit/allow guest access on a clear network that requires no additional client configuration to connect. It is not meant as a way of providing secure access.
So, unless the client only uses encrypted sessions (HTTPS, SSH, SFTP, VPN, etc.), then they are far more secure using a PSK than web authentication.
Edit for the expanded question: Generally speaking a client connecting to the network in any means is not "capturing" any traffic in the air. Attackers capturing traffic will not be connected to the network.
If a client device is connected to a SSID that has no encryption, anyone in the area could "listen in" while there is data going to/from the client. Any of that data that is not encrypted by other means would be easily decoded by someone who wanted to do so. To be entirely clear, "L3 web authentication" provides no encryption. Specifically to answer your question, yes, anyone can capture traffic on an open/clear SSID using web authentication, whether they have a username/password or not making traffic like your example HTTP or print traffic vulnerable.
A PSK is not actually used to encrypt the data, rather it is used as a common frame of reference (or starting point) to allow to devices to negotiate the keying material used for encryption. Having the PSK will not allow you to decrypt the data. However, as BatchyX pointed out, if you have the PSK and capture the handshake, since you have the same "starting point" as the other device (i.e. the PSK), you will be able to get the keying material and decrypt any data using that keying material. This provides much less visibility for an outsider to capture data, as they would need both the PSK and the handshake to do so. One without the other will not suffice.
As for getting the PSK by capturing the handshake, this is a bit more involved, but can be done. Basically, this is a "brute force" type of attack where the attacker uses different PSK values against the handshake until they find one that allows them to understand the full handshake. Once they have this value, then they will be able to easily decrypt any other connection that they capture the handshake for as well. While this is a simplistic description, if you are using WPA2/AES without a "common", short, or dictionary PSK, know that this is very unlikely to occur.
If you wanted a better way of doing this without client certificates, then the most common one is 802.1X based WPA2-Enterprise using EAP-PEAP-MSCHAPv2. This only requires the server side certificate, but is a more involved process to configure the client (although this has gotten much better for many devices in the past couple of years) to authenticate against a RADIUS server. Not only does this make the keying material different for each user, but different for each session as well.
In your coffee shop scenario, I would recommend using WPA2-Enterprise SSID for "company" devices. As for customer access, a second SSID with either web authentication or PSK provides a mechanism for limiting access. Normally most public places go with the web authentication because they can have a mechanism for providing a "Terms of Use" agreement to cover themselves in a legal sense. They leave it to the customer to provide for their own protection of data.
Best Answer
Ok, I think there are two variants to look into this, the problematic part where it divides is when you mentioned OSPF should be used for internal routing. If you want to reach other destination through ISP and use OSPF between sites the ISP routers needs to be part of your OSPF topology, so they would propagate all the networks with OSPF through the whole topology. This picture shows it.
Notice the orange region is also on links between offices, so they are part of OSPF.
The problem here is, that this wouldn't be really possible in real life. You can't manage ISP network, so the solution here is to create GRE Tunnels between every office. That way, the OSPF would use Tunnel interfaces, and from logical part of network it will look like the routers Office A, Office B, Office C are directly connected and can establish neighbours in OSPF through these Tunnel interfaces.
For PAT, I guess you also ment one IPv4 address per OFFICE, not per city. It makes much more sense, that means you will make PAT on every Office router and ISP network uses public addresses to connect between cities. You should also use some dynamic routing / static routing in ISP network, to make sure every ISP router can reach public address of office router ( if you go with the way of GRE tunnels. Having ISP routers part of OSPF topology loose the purpose of PAT, because they can directly see on the inside networks).
Within one office, users in different VLANs will be reachable by inter-VLAN routing (either on L3 switch or router-on-stick solution with subinterfaces). If they want to reach other site directly and you are using PAT, there needs to be GRE tunnel between sites allowing direct L3 connection. I guess you don't want to create rules in PAT for every user.
So to sum it up, I think the best solution here is to do GRE tunnels between sites and do OSPF on these interfaces to manage internal network. For external network (ISP) use again OSPF or EIGRP, whatever works for you.