Last migration I did (maybe 12 months ago), google only accepted passwords as an sha1 hash IIRC. I was told however, that was only an intermediary step, and google runs that hash through another KDF for internal use. The sha1sum of the password is really only used for transport to their API, as an alternative to sending it in plain-text which is what your browser does when you login to google services, so I don't see it as a huge problem. Sure it could be more secure, but interoperability and keeping a relatively low barrier of entry are very important to them too.
But in that case the password has only been compromised on that one website, as opposed to every other website where it's being used (likely a non-zero number of them given the average user's password habits). I'm no security expert but I think client-side password hashing with the domain name as the salt seems like a pretty good idea, especially for sites without HTTPS logins (but it also helps in the case of a database leak even for sites with HTTPS logins). Of course, for non-HTTPS logins a network attacker could modify the HTML form code to remove the client-side hashing without the user's knowledge, but it's still at least as secure as the alternative, modulo 'false sense of security' type arguments.
Edit: never mind the last parenthetical; it pretty much wouldn't help in a database leak at all (just adds one extra hashing step to the cracking process), sorry. Still helps for non-HTTPS logins though.
Edit 2: ... though maybe if the client-side hash were something strong like bcrypt, it would help in the case of database leaks on HTTPS sites that refuse to use strong hashing on the server side for performance reasons. Sorry for the rambly disorganized post.
For MITM attacks, sure. But it's a fairly portable, inexpensive way to make it more difficult to use your password with other protocols. For example, intercepting a plaintext Google password has a decent chance of making someone's bank account vulnerable.
Right. If someone is able to infect the browser with malware, MitM your HTTPS connection, or even just load mixed HTTP/HTTPS content, then they are able to run Javascript in the login page. If they are able to run Javascript in the login page, then they are able to monitor the keystrokes as it is typed in.
This is not theoretical. This is what Tunisia did to Facebook and it's what online banking trojans (e.g. Zeus) do every day.
