OK, I'll be the obligatory critic: I don't see how this solves any problems that TLS client certificates don't. The introduction says BitPay considered client certificates, but doesn't say why they rejected them. And "easy to implement wherever TLS is implemented" sounds like more of a selling point than "easy to implement wherever the Bitcoin protocol is implemented." Also, it seems a little questionable to claim "p…
That's right. But it does reduce the cost of a compromised server. Since no passwords are stored in the server itself, if it's compromised, the user's passwords won't be exposed (even if they're encrypted, they're often weakly encrypted, especially as time goes by).
Passwords should usually not be encrypted. Saying a password is encrypted implies that there is a decryption function that can produce the original password in plaintext. This should not be the case. Instead, typically, a key derivation function like bcrypt, scrypt, etc. is applied. The output of these are sometimes referred to as "password hashes" because like hashes they are not reversible.