I don't typically beat up password managers for PBKDF2, nor for iteration count.
I don't like PBKDF2 but it's the only NIST and FIPS approved KDF outside of Balloon, and unlike Balloon it's widely supported. And while I've never given two fucks about NIST or FIPS, many others have to. Optional support for Argon2, Yescrypt, or Pufferfish would be awesome, but all things considered it's likely diminishing returns for most users.
PBKDF2-HMAC-SHA256 is compute-hard only and fits entirely within registers, so it has precisely zero resistance to acceleration. With an effective ADR of a gazillion to one, it's a perpetual game of cat-and-mouse -- one that is unwinnable if not entirely unplayable by our lowest-denominator devices (iow, if you have a desktop, a laptop, a phone, and a tablet, the highest iteration count you can support is limited by the slowest of these devices.) In the span of a decade, we've gone from recommending 10k iterations to 100k iterations, to 300k iterations, to 600k iterations (based purely on attacker speed, and without any regard for whether PBKDF2 is being used as a KDF or a PHF, no less). It's out of control.
But iteration count is a bit of a red herring. The point of key derivation functions is to stretch a low entropy input into a high entropy key. However, users who are security conscious enough to voluntarily use a password manager are similarity security conscious enough to select a decent master password, likely having nearly as much (or more) entropy as the key they are deriving. For these users, the KDF isn't performing key stretching as much as it's acting as a compression function to coerce the password down to the requisite number of bits. Their master passwords would remain uncrackable even if hashed with MD4. So KDFs (and by extension the iteration count) merely serve as a backstop to protect whatever percentage of users that are security conscious enough to use a password manager, and yet not security conscious enough to select a strong master password. Maybe these are family members of security conscious people, or people who are forced to use password managers at work.
Even still, I would argue that this group of people could be further divided into three more groups:
- those whose master passwords are so weak that no iteration count could possibly save them,
- those whose master passwords have just enough complexity that even 5000 iterations will provide adequate protection,
- those whose master passwords have just enough complexity that 100000 iterations will provide adequate protection.
Remember: at 5000 iterations, PBKDF2-HMAC-SHA256 is nearly as slow as unix crypt(3) $6$ hashes (and exactly as slow as $5$ hashes), and no one has ever accused these hashes of being fast or easy to crack (one word: tomato (iykyk)).
Now let's look at the final piece of the puzzle: context. How exactly has someone gained access to your vault? If the attacker is local, they don't need your master password to raid your vault (and if they do, they'll get it some way other than cracking it.) From the public cloud? There's safety in numbers since the vaults are salted (want proof? Look at the 2014 Forbes breach: phpass, md5, 8192 iterations, 1M salts, I don't think anyone ever cracked more than like 3% of the list.) Private cloud or some other backup media? That narrows the scope, but how much time and money is the attacker willing to throw at your vault?
All of this is to say, the percentage of users who would be at risk from having their vault stolen though some remote vector and subsequently having their master password cracked is quite small, and of these users, the percentage whose vaults would go from crackable to uncrackable solely by increasing the iteration count from 100k to 600k is miniscule, especially if the attacker is able to just throw 6x more compute at the problem. Diminishing returns and such.