There are some other advantages that others have already mentioned, but even if that was all it did it would still be useful in inhibiting an attacker from learning the actual passphrase which many users are likely to have reused on other services.
Sending a password in plaintext over HTTPS is more secure than hashing it in javascript first and sending the hash.
If it's practical to find a hash collision, your hash algorithm is broken.
> which is made easier with the ability to study the client-side code doing the hashing, and taking note of the algorithm and methods used.
The security of a system should not depend at all on that information being secret.
e.g. password + client_salt => hash => send to server => (hash+server_salt)^hash2 => compare to db
By doing this you'd protect a user when their password might be accidentally logged (e.g. Twitter recently). Then if you compromise the hash you don't immediately reveal the password itself, just the text needed to authenticate, which can be changed. If you simply change the salt used client side you may not even need to have the user change their password (although obviously better if they did).
That said, I don't think this is required, but there is actually a case for it. Also obviously you should never log the password, but mistakes are made. This helps mitigate the risk of that password being exposed.
Along the same lines though is OPAQUE PAKE, where the server doesn't need to store a password hash, only a salt, making server compromise far less dangerous, it's quite elegant.
There's no implementations so far I believe.