I came here to write that I fully agree, but actually it’s complicated.
If bitwarden is hacked, high-profile (or otherwise interesting to the attacker) users could be targeted and any weak master passwords will be catastrophic, revealing all logins (plus what they are for!) for the respective users. The master password is not needed for the default usage of syncing the encrypted vault between devices.
Possible resulting implementation: When creating a vault on a device for the first time, add to it a secondary password for server authentication. The master password will not need to be stored on the server permanently, not even in hashed form.
I’m undecided if this secondary password should also be used by people to log into the vault website - obviously they would only be able to do “account operations” that way, such as deleting the account. Anything that involves modifications to the vault still requires the master password to decrypt the vault on the server side.
Logging into the vault should still be possible using the master password too, for the use case of working from “a friend’s computer” without any Bitwarden software on it.
Furthermore, obviously it should be possible to download the encrypted vault again in a case when adding a new device - in an extreme case the user loses all devices with Bitwarden on them, so they lose access to the secondary password.
So in all those cases where the server actually needs to authenticate the user with the master password after all, how should it do that? Assume that we avoid storing the master password on the server in any form, not even salted+hashed.
One approach would then be to just try to decrypt the vault with the supplied password and then check if the result is gibberish. But then this operation of “decrypt and check for correct format” is just another piece of code that executes and returns whether the password is valid - just like the hashing function currently in use!
For a small vault it could actually be faster to attempt to decrypt than doing an iteration to check the password of a password scheme like PBKDF2. Relying on “decrypt and check for correct format” would then enable a bitwarden hacker to search for weak passwords faster. IMHO it’s better to rely on an authentication method that many people have refined over multiple years to withstand all known types of attack…
Or to turn around this argument: If bitwarden.com is hacked, the attacker could actually attack the encrypted vaults directly using the “decrypt and check for correct format” approach. They might not bother with the passwords because those are harder to brute-force, by design.
Corollary: The encrypted vaults should withstand quick brute-forcing at least as well as the passwords. That’s also important for the case that the attacker gets hold of a device of the user…
My personal conclusion: Separate account/vault passwords would not necessarily improve the security of the system.