TLS provides much the same protection from eavesdropping, and is practically the universal standard today. Modern password hashes are superior to the augmented authenticator form SRP stores. And you cannot simply "replay" a TLS session. In the modern web stack, the only thing SRP actually accomplishes is the authentication of a TLS connection with a password rather than certificates, which is a fringe use case.

PAKEs are interesting in custom protocols; for a recent and valuable example, see Magic Wormhole. But the reason you don't see them everywhere is that they're just not that useful in web applications.

You treat TLS like a silver bullet. Yes, it's common, but so are TLS intercepting CDNs like Cloudflare which can do a passive attack to find out user passwords. Also, if the password never even enters your network, you are safe from any misplaced debug setting that accidentially logs your passwords (happened to facebook).

The only disadvantage from SRP is that you can't do server side stretching which means you are limited by device concerns like battery power for your stretching parameters.

From what I've gathered from the discussions & links on here:

Our current solution for password authentication is perfectly fine, unless you distrust your CA's.

SRP itself is a bit of a mess, and has gone through a lot of iterations to fix its faults. OPAQUE is probably your best bet. But implementing the protocol seems like overkill for password auth, and is easy to implement improperly.

Such PAKE's will likely prove to have other good use-cases, however, like magic-wormhole.

This sounds about right? Nobody really "trusts" CAs, but the whole WebPKI system that surrounds it is a lot more intricate than most people understand, and we've reached a sort of trust detente with it. The pressure to replace it root-and-branch is mostly gone now, and whatever replaces it, it won't be PAKEs.

I like PAKEs just fine and in particular really like Magic Wormhole.