The hash is not constant.

With public key crypto you can implement a challenge response. Server generates random garbage, send to client, client signs the garbage using priv key, sends it back as a hash that the server can verify using pub key.

Another version of this is with shared secrets instead of public/private, by replacing the signature with simply HMAC(secret, garbage) and keep rest of flow same as above.

Yeah, once you get to the ZKP approach, which is what you're describing, the benefits are more significant.

> With public key crypto you can implement a challenge response.

Or just use a client side TLS certificate to authenticate instead of or in addition to the username and password.

There are like a dozen other posts where I answer this question so I'd recommend just going to my comment history.

Because many inputs map to that hash (the hashing function is surjective instead of bijective). People re-use passwords all the time. If the hash leaks it will only affect the particular service.

Because pass the hash only works for the current server. People reuse passwords, so without brute-forcing you are out of luck.