Speed can be an advantage for one reason and a disadvantage for another.
When it comes to password security, the low cpu/memory requirements of a cryptographic hash brings a disadvantage, namely than if records or the database are exposed or hacked, an attacker has minimal work to do in order to brute force those hashes into a plaintext password.
This is because passwords are typically short and have less entropy than the preimage security of the hash function. If the passwords are huge and random, say 32 random letters and numbers, then a single fast iteration of the hash function is more than enough.
For security, you want a "password hashing function" to take as much time (compute resources) and memory as is feasible to slow down bulk attacks. However, this becomes a disadvantage to the server which will compare a hash to the database value, since in most cases that server must compute the hash from a user provided password.
An attacker may exploit that disadvantage by consuming large amounts of resources through coordinated mass login attempts of known or expected usernames, effectively a low bandwidth denial of service attack, the server is so busy keeping up with bogus login attempts that real users cannot login. This can be mitigated by throttling access attempts per IP address, per username, and also adding a delay before a login failure is shown. If the user does not exist, the server should not hash the password, but should return an error with an appropriate delay as if the user did exist, so that an attacker cannot infer the presence of usernames in the database.
PBKDF2 is an extremely common password hash, and at its core routinely uses HMAC, so something like 40000 rounds of PBKDF2-HMAC-SHA256 actually may take around 80000 times longer than a single hash iteration. If the server could previously perform 4 billion hash iterations per second, it may now only be able to do 50000 hashes of PBKDF2 before saturating its CPU completely. If you want no more than 10% of resources allocated to password checking, it would need to be throttled at 5000 login attempts per second... which may sound like a lot, but how many people do you think log into something like Gmail, Lastpass, or Salesforce at around 9am on a Monday?
There must be a balanced configuration and enough hardware to handle all user logins even under heavy load without a noticeable delay for those users, and prevent bad actors from denying service to those users. The strength of the password hash may also need to change over time as the resources of attackers increase, threat models change, etc. The cost of reputation damage may be many times higher than the cost of hardware to perform very expensive password hashes.
Are there other situations where being fast is a disadvantage? Off the top of my head I really cannot think of any, hash functions are typically used as part of a scheme, like digital signatures for example with a computationally expensive asymmetric algorithm involved, the security in that case comes from the size of the hash and the effective strength of the signing key, not the speed of the hash.
