Because then it would take more time to brute force. I mean if hashes were near instant then even without any theocratical collision that wouldn't be good, that hash would fall faster than a slower one!
Depends on the workload, and the article does not explain anything there so it's completely useless.
For "slow hash" workloads such as password hashing you want a slow hashing function, but none of the three hashes listed is acceptable for password hashing anyway so their comparison is not really relevant (they can be part of a password hashing strategy e.g. as the crypto hash function of PBKDF2 through HMAC[0], but in any case you'll want to size your iteration based on the acceptable time spent hashing in the normal workflow).
For things like checksumming, you do care about checking throughput and you care that payloads are hard to craft (so it's not feasible to alter the file but keep the checksum unchanged), depending how important the checksumming is you may accept tradeoffs e.g. if you want to be resistant against accidental corruption CRC32 might be enough (very fast but easy to fake), if you want to protect users against malicious attacks (e.g. distro package repository) you'll want a good cryptographic hash as validation is more important than raw throughput. MD5 can work there, maybe more on the CRC32 side or as an early validator (e.g. with a fallback hash so MD5 is used to weed out some stuff fast and potential false positives are eradicated through a second hash function)
For hash maps, you want speed and spread across buckets.
To provide flexibility, core crypto hashing function try for two goals: 1. throughput speed and 2. limiting collisions
[0] if you want to hash user passwords — and you should - there are currently three known good choices, all variable workloads (means you can increase the number of "rounds" without decreasing the entropy, making the passwords as hard to crack as you can afford): PBKDF2, Bcrypt and Scrypt. The first 2 are CPU-hard (the variable workload deals with the amount of computation only), the last one is also memory-hard (it also takes a variable amount of memory — configured when hashing — making it much harder to parallelize on GPU or ASIC). The point of variable workloads is that as CPUs improve you can add more rounds to the process to keep up (for instance the original PBKDF2 RFC recommended "1000 iterations" in 2000, the current standard is generally 10000~20000 and OWASP recommends 64000. Generally speaking you want to give it as much time as you can — on your production hardware — without user disruption, shooting for at least 250ms is a good idea in most systems which'll only rarely need to "login" users and apply this delay)
Where people always seem to get this idea from is password storage. In that scenario, the attack is an attacker trying to brute force guess a secret input from the hashed output. Since passwords don't tend to be very good, the number of hash operations required in that attack is low enough that suddenly the speed of the hash function DOES impact how feasible the attack is.
The solution to this problem isn't that all hash functions need to be slower, it's that people should stop using fast hash functions for password storage. Fortunately there are a number of ways to turn a fast hash function into a slow password storage function. Or you can use a function specially designed for password storage like bcrypt or scrypt.