PBKDF stretching is a mitigation against bad passwords. The difference between PBKDF2 and argon2id is marginal because you'd need to have chosen a password that's in a narrow window between "So bad that PBKDF2 doesn't save you" while "Not so bad that argon2id can't save you either".
Stretching isn't magic. If your password is 'jszymborski' then no practical KDF will prevent bad guys just guessing "Um, maybe it's just jszymborski?" and getting in. And on the other hand if it's two dozen random alphanumerics you can use SHA256() as your KDF and be absolutely fine.
Because their users will (even if told emphatically not to) use bad passwords, Bitwarden needs a PBKDF with stretching here to buy those people more margin, but nit-picking the choice of PBKDF is missing the wood for the trees. As an end user the right thing to do regardless is use good passwords, which of course is how we got here...
PBKDF is (at best) a sub-optimal choice: their entire business model is zero-knowledge storage of cryptographic secrets. They really need to switch to Argon2 and some sort of PAKE protocol.
However, they need a cross platform solution that integrates with .NET and will also work on a budget smartphone. I've sketched out such an architecture, but I lack the time and budget to do it.
Stretching isn't magic. If your password is 'jszymborski' then no practical KDF will prevent bad guys just guessing "Um, maybe it's just jszymborski?" and getting in. And on the other hand if it's two dozen random alphanumerics you can use SHA256() as your KDF and be absolutely fine.
Because their users will (even if told emphatically not to) use bad passwords, Bitwarden needs a PBKDF with stretching here to buy those people more margin, but nit-picking the choice of PBKDF is missing the wood for the trees. As an end user the right thing to do regardless is use good passwords, which of course is how we got here...