Their justification boils down to "either the attacker has full access to a compromised devices, or they don't." Meaning they could re-steal your master password AND encrypted database, or neither.

I don't believe that is true. Let me give an example where their justification breaks down:

Your master password is stolen, the attacker break into your DropBox account and associate it with the attacker's device, DropBox is inadvertently sharing your Bitwarden database.

You discover the break-in, change your Bitwarden master password, change your DropBox password, but forget to un-trust existing devices from DropBox. So now the attacker continues to receive your Bitwarden encrypted database via DropBox.

But good news, you think... You've changed your master password! But nope, the actual encryption key wasn't rotated, and the attacker continues to have access to everything. You're rotating passwords on all of your compromised services, only to provide the attacker with the new passwords, opps!

Their whole justification is: "But how would they get the new database?" And frankly numerous ways. Plus their workaround is pretty embarrassing:

> If a user has a pressing need to rotate their account’s encryption keys it can be achieved today through a manual process of exporting all vault data, re-creating the Bitwarden user account (delete and register again), and then reimporting the vault data back in.

Wow really? And this makes them look really bad:

> Rotating an encryption key would require that a Bitwarden client application re-encrypt the user’s entire vault (including binary file attachments). This operation is both expensive and error prone and would pose a high risk for users to end up with corrupted vault data.

So you've written such great software that it cannot reliably decrypt and encrypt without potentially corrupting the database? Awesome.