Actually it looks like Argon2 is being discussed as of just a couple hours ago https://community.bitwarden.com/t/switch-to-argon2/350/24
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...
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.
Quick googling on this topic says that as of 2018 they were using authenticated AES-CBC.
I know that encryption primitives are almost never the breaking point in systems like this, but I wonder in situations like this where breaches would allow adversaries to attempt offline attacks whether they are particularly pertinent.
Specifically, while the number of iterations on the PBKDF2 SHA-256 function are high (100,001 on the client), PBKDF2 always felt to me like a footgun when compared to scrypt or argon2 which don't have as many (any?) insecure modes of operation.
The website states that AES is used, but is it in an authenticated mode (e.g. GCM ?)
Finally, their website states that they use "popular and reputable crypto libraries" and that they don't roll their own crypto, but the libraries they use are awfully low-level. Something like libsodium or FilSottile's age would be something I'd be more comfortable with when considering a hosted method.
In the meantime, I think I'll keep using KeePass2 (w/ Argon2 and ChaCha20) and synch'd with SyncThing to minimise my attack surface.