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
This is actually default behavior.
The only way a local login will even be attempted is if all other authentication types fail (TACACS and/or RADIUS).
So in your case, the only time your local password database will be consulted is if the TACACS server(s) fail to respond to any requests. If you attempt to login, but TACACS rejects your password, the local database is NOT consulted.
From: Juniper Authentication Order Methods
If you're seeing different behavior, check for the following configuration statement (be aware it has sub-options, for more info see Configuring Authentication Order):
If this is configured in the right way, the authentication database WILL be consulted if the TACACS server fails to respond OR rejects a password attempt.
So to be extra clear, you do not want
authentication-order
configured at all to achieve the default behavior.