I'm not going to argue but I might as well explain some of the uses here. For example, encrypting clientside and not decrypting serverside will mean it's impossible to have a plaintext password leak in the future, which decreases risk.
It also forces passive MITM to become active. Turning Eve into Mallory gives theoretical attackers much more work. There are more benefits beyond this.
What you're thinking of is using this for actual password protection, which it won't provide. It can't be used as a TLS replacement. If you've actually read tptacek's big blog post about this you would notice it has to do with using js crypto being used to protect something, which this won't provide, but it can successfully be used to protect a service from itself and many other things. It's impossible to know all the details and benefits and pitfalls of their scheme though, without all the code from the server too.
> encrypting clientside and not decrypting serverside [...]
...will also enable anyone with the encrypted password to log in, in a sort of pass-the-hash scenario. To protect against plaintext password leaks, you'll want to run PBKDF/*crypt on the server, not encrypt the password. See the Adobe password leak for the gory details.
This is why all the security experts say that JS crypto is useless.