Cisco IOS public-key auth with privilege 15 and no password

I would do a debug on your TACACS+ server while you are trying this.

I'll assume that you only want to use TACACS authentication and only fall-back to local logins if it can't access the server?

Try using this:
aaa authentication login default group tacacs+ line
aaa authentication enable default group tacacs+ enable

Also see this site: It has some good examples and explanations

http://my.safaribooksonline.com/book/networking/cisco-ios/0596527225/tacacsplus/i13896_heada_4_2#X2ludGVybmFsX0h0bWxWaWV3P3htbGlkPTA1OTY1MjcyMjUlMkZpNTAzNjNfX2hlYWRhX180XzEmcXVlcnk9

My guess is that since you have the "local" keyword in:
aaa authentication login default group tacacs+ local line

The TACACS+ authentication returns a fail, so the router tries doing local authentication. I guess you should provide us with the line vty sanitized configuration. If you have
line vty 0 15
login local

Then it would do a username/password authentication otherwise its doing password

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.