(Not a cryptographer either.) Consider two different application areas for a “hash”:

- Message digest: compute a fixed-size summary of a (relatively) large amount of data, for things like content-addressable storage or signing. You want this to be fast. (Nobody is going to brute-force even a 1K chunk of unknown data.) Examples: SHA2, Blake2b, Keccak aka SHA3.

- Key derivation: compute a small chunk of randomy data from a still-quite-small amount of substantially nonrandom data, for things like turning a user-specified password into an encryption key or (with a random salt) something you could store. You want this to be slow, even on a massively parallel machine. (You aren’t going to be processing logins that quickly; on the other hand, everybody’s going to be all over your leaked passwords table with their GPUs.) Examples: PBKDF2, bcrypt, Argon2id.

That's true for passwords (where you don't really use raw SHA or something, but rather something like bcrypt which is intentionally slow), not necessarily for all uses of passwords. E.g. computing a SHA sum of some binary doesn't need to be slow, it just has to be practically impossible to create a collision (which is what's required of every good cryptographic hash function).

Yeah this is a super common point of confusion. You need to worry about slowing down a brute force attacker when you're trying to protect a low-entropy secret, which basically always means user passwords. But when your secrets are big enough, like 128 bits, brute force becomes impossible just by virtue of the size of the search space. So for most cryptographic applications, it's the size of your key (and the fact that your hash or cipher doesn't _leak_ the key) that's protecting you from brute force, not the amount of time a single attempt takes.

Yeah SHA3 isn't directly for password hashing. You should use a memory strong PBKDF (password based key derivation function) like Argon2, bcrypt, or scrypt. These functions are all constructions that run the hash many times, so the underlying hash speed is irrelevant

For high entropy inputs, like for a HMAC signature, you want the hash to be fast because its practically impossible to brute force the 256bit input key, and you often apply this to large inputs.