I was being sarcastic, but, why wouldn't client-side hashing of passwords prevent some class of attacks that can be used when plaintext passwords are accidentally stored(and eventually exfiltrated) - eg credential stuffing?
So while you can still authenticate as the user to say facebook you can't login to their linkedin account. Assuming, facebook and linkedin don't use the same client side salt.
There is no advantage if you use proper security practices like storing a hash and salt.
Whoever created the login system probably is a different person than who added the logging system. Perhaps the logging system should've discarded login attempts or masked the credentials but there's probably a dozen ways to login and they'd need to know all of them and possible futurely added ones.
It seems a bit more practical to have the system send a safer version of a parameter to the server instead.
You could hash them again before they hit db, but then your not really pre-hashing the passwords clientside. And if you want to change your hashing algorithm or parameters, users can't login until they update their clients.
But, by not sending the actual user-entered password, it prevents me from logging the user-entered password in plaintext.
If I did make a mistake and logged the users email and "Y", and I got hacked, the hacker could not take the email and "Y" and try to log into a variety of other online services using the same credentials. This is the credential stuffing I was speaking of.