One important reason we hash passwords is protect what is essentially a user secret (one which the user may use across many different services) from prying DBAs. In that respect client-side hashing (with salting) makes perfect sense.

The other major benefit of server-side hashing, to what you're correctly surmising, is that it prevents certain privilege escalations. A read-only database dump (from e.g. SQL injection in to a SELECT query) can otherwise be used to gain read-write access by simply copying dumped passwords from the database back in to the login form. The thing is, server-side hashing doesn't actually prevent this attack, it merely slows it down. It also doesn't help at all with weak passwords.

In any case, to address your concern you can also simply run the client-side hashed value (which could and should be produced by something like Argon2) through a single round of SHA2.

There are ways to improve security via encrypting the password clientside with a nonce and avoiding passing raw text over the request to the server (which should be https not http) but I believe it isn't considered necessary above the inherent security in most circumstances.

You could just hash the hash that the client sends, no? Then you never know their password and it's still stored securely.

If the client always hashes the password in the same way (no nonce or usage of encryption) then the password essentially becomes the hashed string with some extra clientside code you're burdened with forever. And since that same hashing will need to be done whenever they log in the hashing algorithm needs to be in the client side code sent to everyone... meaning an attacker would have a bit of obscurity in their way and just need to regenerate a rainbow table based off of your hashing algorithm to test common/weak passwords.

It's not about the security, it's about preventing side-channel leaks of the plain password (e.g. incorrectly sanitized logs or buffer overflows). Having a data breach of your site-specific hash is much better than leaking the user's password that an attacker could use on any website.

Your site specific hash, if leaked into logs and generated using a fixed hashing algorithm, would just be a step of obscurity, a rainbow table generated according to that hashing algorithm would be able to extract the original typed password pretty reliably for use in compromising other accounts held by the individual on other sites.

There are ways to actually add security above SSL but they require a per-session nonce. The most secure versions of these operate on some sort of out-of-band time-scrambling algorithm that's issued to users on an individual basis (usually a dongle) which is basically a nonce that's been pre-arranged a few years in advance, these can (if done correctly) provide all the security of on-demand generated nonces and physical keys combined.

Fixed hashing algorithms add such a negligible amount of security that I'd prefer to avoid them due to the tech debt their existence incurs outweighing their advantage.

Their password would have to already be in a rainbow table, and at that point nothing can help them. But I agree it's kind of pointless, I was just arguing that there is a benefit even if negligible. If you want real security, WebAuthn is the future.