There is a subtle cargo cult fallacy that occurs in many crypto construction competitions: that resource light (time, RAM & operations) in hw/sw is "good." Certainly, minimum performance is necessary but being too cheap means brute-forcing is also cheaper. I wish resource-adaptive algorithms that require a minimum of RAM and ops in both hw and sw optimized implementations a-la scrypt were the rule, not the exception.
State actors can easily afford ASIC AES and SHA2 brute-force farms, and that's a concern, especially with monocultural recommendations to "always use AES/SHA2." Now that Keccak's been chosen as the basis for SHA3 in-lieu of more hw expensive alternatives like ECHO, the cost of cracking has been reduced for future scenarios. Do we really want to slash the security margin for a modest bump in runtime performance?
When one hash is a billion times too fast to securely store passwords, and another hash is ten billion times too fast to securely store passwords, the speed difference doesn't matter.
All the hashes you'd care to look at are within an order of magnitude of speed. They all need to be repeated a very large number of times to fight brute forcing. Using more repetitions for a faster hash is so utterly trivial it's not even worth mentioning in the context of security. There is zero difference in security margin from the speed of a hash.
And yes, memory-intensive algorithms are good for passwords, so you shouldn't be caring about normal hashes at all.
Brute force is irrelevant in hashing. The faster the better.
PS: this is because the complexities for attacks are too high. For SHA-3-256 you need 2^128 operations to approach finding a collision. Whatever your speed you will never reach this amount of computation (or storage).
You've confused password hashes with general-purpose cryptographic hashes. The latter is a building block of the former. SHA-3 is the latter: a general-purpose hash.
State actors can easily afford ASIC AES and SHA2 brute-force farms, and that's a concern, especially with monocultural recommendations to "always use AES/SHA2." Now that Keccak's been chosen as the basis for SHA3 in-lieu of more hw expensive alternatives like ECHO, the cost of cracking has been reduced for future scenarios. Do we really want to slash the security margin for a modest bump in runtime performance?