People stuck on a slow mobile network would tend to disagree.

That is picking my comment out of context. Fortunately we don't change passwords all that often. But that was not my point - rather that we already accept so much JS bloat on the web, that doing the same for password change is no different except it provides some actual benefit.

   The server can't verify such claims without actually inspecting the password because the client is (from a security standpoint) untrusted. In the HTTP/HTML web client/server model, there is no effective way for the server to guarantee that the client is truthfully executing certain algorithms. That's fine, but it does mean that the server is the only source of truth for these type of security claims.

Not true. Zero-knowledge proofs can prove that "This hash comes from a password that meets all requirements", without providing the password to the server, yet it knows that it is good.

   That's a dangerous road to take. Such a marginal security improvement still comes at a cost of increased complexity and maintenance burden.

Not at all. This is security best practice; lock things down as much as you can, and only open up for attack vectors when you have to.