Unless you are have a formal proof of your entire application plus operating system and enforce very long passwords, the choice between bcrypt and Argon2 isn't improving your security. Even if that describes your situation and custom bcrypt silicon becomes available, you can buy some and increase the work factor. Also if this describes your situation, trusting JWT is a huge risk. For any web application, your time is better spent closing run of that mill web vulnerabilities.
I'd argue (though PHK himself disagrees) that yes, PHK MD5 crypt() is still an acceptable choice in 2020 for exactly that reason. You can add a bunch of rounds to defeat a reasonable attack, and it's unlikely this is your system's weakest defence. Should you build new green field systems intentionally with PHK MD5? No, no reason to. But you are kidding yourself if you believe that's the weak point in an existing system or in a compatibility mechanism.
Toy systems that just do MD5(MD5(password)) are screwed because they don't have any salt, but PHK MD5 uses salt so all the time-space tradeoff attacks are made irrelevant, bad guys will need to brute force each account they want to attack individually.
If which crypto hash to use is a major security consideration you are already Doing It Wrong™ because the only point of these systems is to store human memorable passwords, and human memorable passwords are hot garbage anyway. Either outsource the human authentication problem to somebody else or, if you are quite sure that's strategically unsound (e.g. you want to be Amazon or Apple with fingers in every pie) then require passwords not match PwnedPasswords and either mandate or at least strongly encourage a second factor, with at least TOTP and WebAuthn options offered.
