No, you're confusing them with password hashing functions (bcrypt, scrypt) and password-based key derivation functions (PBKDF1, PBKDF2). These _are_ cryptographic hash functions, but they are designed to iterate many many times (the exact number is customizable) in order to take a given amount of time.
"Generic" cryptographic hash functions like SHA-1/SHA-2/SHA-3 (or BLAKE, or MD5) don't iterate more times than is necessary for security, and are designed to be as fast as possible. This way, you can hash multi-gigabyte documents in a fraction of a second.
No good hash functions are usually fast. You're talking about "password hashing function", and I can understand the confusion. Maybe if people decided to rename these "pash" it would be easier.
Anyway the state of the art here is Argon2 which won the latest password hashing competition: https://password-hashing.net/
I think we're circling back, KDFs are definitely not suited for hashing passwords. For example, you wouldn't use SHA-3(password) as a password hashing function, but it makes a fine KDF.
If you're thinking of PBKDF2, it's a "password-based" KDF as its name hints. While both password-based KDFs and password hashing functions seem to have common properties, I think the term "password hash" has caught up more (specifically thanks to the password hashing competition).
For passwords, yes. You want your hash function to be as slow as possible to reduce the impact of brute force attacks.
But for all other cryptographic purposes like message integrity checking, file verification, signing, or fingerprinting speed is extremely important.
In these cases, the input to the hash is generally public, so there is no reason to even try bruteforcing. And even if you did, these inputs are much longer than passwords.
"Generic" cryptographic hash functions like SHA-1/SHA-2/SHA-3 (or BLAKE, or MD5) don't iterate more times than is necessary for security, and are designed to be as fast as possible. This way, you can hash multi-gigabyte documents in a fraction of a second.