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.