Because iOS (and Mac OS) automatically connects to known WiFi hotspot names, it's possible to create a hotspot named the same as Starbucks's WiFi, even if you're nowhere near a Starbucks, and iOS will happily connect to it if possible (unless other preferred networks around and it picks them over you).
Also, a lot of smaller coffee shops will just set up a wifi router and give it a password and call it done, when many of them have inherent exploits.
On top of all that, there are lots of Asus routers out there running firmware that can be remotely exploited and for which there is no patch[1]. Or Linksys routers[2]. Or D-Link[3].
All an attacker needs to do is change your DNS server settings and they can send you to any server they want instead of the server that you expected. They could redirect all HTTP and HTTPS requests to common services through their servers, MITM your connections to Facebook, Twitter, Apple, Bank of America, your e-mail, your health insurance website, etc.
On its own it's safe, but if you have control of someone's WiFi router (which is apparently trivial) then it's entirely possible for someone to snoop on a huge swath of your supposedly secure internet traffic.
The only real saving grace here is that OS code signing hasn't been compromised, so the system won't install a backdoor'ed 10.9.2 update. At least that part of the chain is secure and people can update.
If you configure that hotspot name with WPA-PSK, it should not attempt to connect to hotspots with the same name that are not WPA-PSK. If the hotspot it tries to connect to does not have a matching PSK, it should fail the handshake (and no, the client isn't disclosing the PSK to anyone during the handshake). If any of this is not true, that would be another vulnerability.
Also WPA-PSK is useless for coffee shops because you have to give the PSK to everyone, and with that the ability to impersonate the AP. For that purpose, EAP/TLS is better, assuming you take care to verify the AP's certificate.
Anyone can hide his access point in a backpack and claim to be Starbucks. Or anything else - most people don't care, they'll hook themselves to just about anything.
This isn't true of home networks using PSK, where the AP and the client need an identical PSK in order to authenticate each other. Yes, each other - if you successfully connect to an AP using a PSK, you can be pretty sure that AP knows the same key, and probably isn't someone impersonating it (note however that anyone with the PSK can impersonate the access point).
Remember kids, when you connect to a network without a PSK or more elaborate authentication where you verify the identity of the AP, you generally have no idea who is operating that network.
What stops someone from doing that anyway, with their own hot spot, and just serving a self-signed certificate? Will the browser remember the old certificate, and put up the warning?
A self-signed certificate will throw an error in the browser because the certificate chain isn't trusted (even if you have the appropriate key).
In SSL, you have the certificate and the key; the key is private and secret, and the certificate is public. A public certificate which is wrong (e.g. self-signed) does you no good because browsers won't trust it (and many of them have made it frustrating to try to bypass the warning).
Wouldn't you need to have control of the router Starbucks is using to set up the MITM attack?