Wholeheartedly agree, however The Changelog Podcast helped shift my perspective on this. It's really about not having the responsibility of storing and maintaining passwords.
You should never store passwords anyways. You store hashes. I don’t see the issue. If you don’t trust yourself to keep a hash, maybe don’t store user information at all.
Most leaked passwords online come initially from leaked hashes, which bad actors use tools like hashcat to crack.
If your user has a password like "password123" and the hash gets out, then the password is effectively out too, since people can easily lookup the hash of previous cracked passwords like "password123".
This is how it should be done. But it still doesn't protect users fully, because attacker can try to brute-force passwords their interested in. It requires much more effort though.
Salting already fixed this decades ago, and most modern password libraries will automatically generate and verify against a hash like <method>$salt$saltedhash if you use them instead of rolling your own.
So if they don't want to store your passwords because they do not want the responsibility of keeping it safe, should you trust your credit card and other personal information with them?
You'll find that opinion is still divided among these three options. And bcrypt is harder to mess up. It has less parameters (it doesn't fall apart as easy) and salting is built in, whereas its not for scrypt and argon2. If, knowing nothing else about the competency of the programmer, I had to choose between an application using scrypt, argon2 and bcrypt, I'd pick bcrypt any day.
"But, seriously: you can throw a dart at a wall to pick one of these... In practice, it mostly matters that you use a real secure password hash, and not as much which one you use.