Because it's comforting to know that you handed over your private information to a man-in-the-middle and nobody else.
Note that with self-signed certificates the man can only attack in the middle on the very first connection. After that the other end will be known (not authenticated, but known!) and the browser can guard that.
Currently, I trust my home DSL connection to not have eavesdroppers everytime when I authenticate to some web service over HTTP. Doing the initial connection once using the same network wouldn't be any worse but it would be much better when using any public wifi when I don't know exactly who is providing the service or who is intercepting the wireless connections.
When I want to read an essay on some random website, to I need to now that the website owner is who they say that they are? Isn't self-signed HTTPS better than just plain old HTTP? Or is it better that we only use HTTPS for a select few sites that aren't self-signed and HTTP everywhere else?
But 'either you care or you don't' seems too inflexible to me.
For example, I might care that my bank has a certificate signed by a CA.
But for some usergroup's online forum, a self-signed certificate is enough. Sure, we might get some MITM but the barrier to this is so high and the relative importance of the online forum so low, it seems an adequate trade-off. I'd say there's a higher chance of the server hard drive failing than to see an actual MITM attack on a given niche server.
But overall, as I've said in another message here, I see this whole centralized design as flawed and much too expensive. Certificate info should be a DNS attribute.
It's much like bumping onto someone at the gym frequently but not really knowing their name or who they are. You can still trust that he's the same guy, sans having had a facial plastic surgery.
Sending passwords over plaintext http is just stupid. To mount a man-in-the-middle attack you actually have to do something and position yourself between the two ends, not just listen to the passing network traffic.
So, you might log on to Twitter at home (a relatively safe connection) and receive their public key and then use that to communicate with Twitter again later in public wifis or among middlemen at the airport. The browser would refuse to connect if the key doesn't match, much like ssh will complain if the host key fingerprint has changed (and require you to do manual purging of your known_hosts file).
Gmail is the only one where you can tap "Always use https" on. To Facebook you can connect with https://facebook.com but I don't know whether any auxiliary or Ajax/XMLRPC connections will use that.