Their rationale is probably because those two don't scale very well when you want to make their efforts count, whether bcrypt's hunger for CPU or Argon2's hunger for CPU and/or RAM. Bcrypt is very capable at bogging things down when you have lots of users authenticating very frequently, which is often the case with a POP3 server. A mere 100 e-mail clients authenticating every 2 minutes on average to check for new mail incurs a significant load even with a mild bcrypt work factor. On the opposite end PBKDF2 with 5000 rounds is much leaner, and if you enforce long passwords - which is immensely important no matter what password-hashing you use - then even fewer rounds are needed.

Well if you want passwords to be difficult to crack if an attacker gets access to the hashes, you kind of just have to deal with it.

Yes, and enforcing long passwords is the primary and most important way of dealing with it. Enforcing ridiculously high CPU/RAM use for authenticating is a cost that both sides have to pay, but in itself it doesn't solve the problem at hand.

I'm wondering, if pop/IMAP auth is so costly, why POP3/IMAP community not allow user to get session token and auth with it? Like JWT or anything with similar security properties. Both protocols are easily extensible...

It's only costly if the software (or its administrators) decides that it has to be. This particular product's approach (5000 rounds of salted SHA512) is not very costly, nor is it inherently insecure.

Just assign passwords.

You are basically saying sha256 is prune to attack. As long as they salt the password, it should be fine.

It is not. Even long/"complicated" passwords usually do not have much bits of entropy, which is why you need an expensive hash to make bruteforce attacks difficult.

How is f2b relevant to hash cracking mitigations?

At least it prevents remote brute-forcing.