Short answer: because the password is used to encrypt the user's randomly generated seed, then the resulting ciphertext is stored on the server. If we didn't hash client-side and sent passwords in plaintext to the server, our end-to-end encryption scheme using password-based encryption would be broken (though I know that’s not exactly what you were saying)
Long answer: Based off my understanding, we do implement something analogous to SRP with some minor differences.
We'll have supporting documents explaining our approach complete with diagrams soon. But for right now, this is close to what the architecture looks like for clarity:
https://user-images.githubusercontent.com/26468430/69532862-...
In order to be fully authenticated, the client must first prove they know the password token. The server then sends the client the password encrypted seed, then the client proves they can decrypt that seed (using Diffie-Hellman). So functionally the client is proving it knows both derivatives of the password to the server.
Note there are 2 major differences between that image and what's currently in the code:
1. We also do a single SHA-256 hash of the password token before storing it on the server (prevents someone with access to only the server's data from passing round 1 of our authentication flow)
2. The optionals are not optional anymore, what I described above is how it’s working today.
Disclaimer: there are a lot of missing pieces in the above description. So if it feels like there are gaps, that's why. It's difficult to explain the full scheme in a single comment like this.
Our approach is pretty similar to Firefox's described here: https://hacks.mozilla.org/2018/11/firefox-sync-privacy/