I know that MD5 should not be used for password hashing
Indeed. However, that's about the direct applicability of MD5 to a password or to use it with just a password and salt. In that case MD5 is less secure than a dedicated password hash with a work factor, at least for common passwords and pass phrases.
However, the use of MD5 within a PRF (HMAC) and within a password hash is still OK as it relies on pre-image resistance for security, rather than collision resistance.
I'd rather not bet that MD5 stays secure for pre-image resistance though. Attacks only get better and although I don't see any progress on breaking MD5's pre-image resistance, I would not rule it out either.
Identifying malicious files, such as when Linux Mint's download servers were compromised and an ISO file was replaced by a malicious one; in this case you want to be sure that your file doesn't match; collision attacks aren't a vector here.
MD5 is still secure to check hashes from another server as long as hackers cannot alter the input of the MD5 hash. However, for something like a full ISO, I'd say that they would have plenty of opportunity bringing in binary files that seem innocent with regard to contents, while they alter the intermediate state of MD5 vulnerable to collision attacks.
That was not the attack that you referred to; in that case the MD5 hash on the official server was different from the one calculated over the ISO image.
But attack on file distribution do rely on collision resistance, and this kind of use case can definitely be attacked. It would probably not be all that easy (correctly lining up the binary data required for the attack at the start of the ISO and such), but it is a vector of attack none-the-less.
The same goes for SHA-1 in Git by the way. Not easy to breach, but far from impossible, whatever Linus says.
Finding duplicate files. By MD5-summing all files in a directory structure it's easy to find identical hashes. The seemingly identical files can then be compared in full to check if they are really identical. Using SHA512 would make the process slower, and since we compare files in full anyway there is no risk in a potential false positive from MD5. (In a way, this would be creating a rainbow table where all the files are the dictionary)
Sure, if there is no possibility of attack or if you compare the files fully anyway then MD5 is fine.
However, if there is a vector of attack then you need to perform a full binary compare even after the hash has matched. Otherwise an attacker could make you retrieve the wrong deduplicated file. If you'd use a cryptographically strong hash then you would not have to perform the full file comparison at all. As others have noticed, a 256-512 bit hash is a lot easier to handle than performing a full file compare when storing. Passing over the file twice is not very fast either; all the speed advantages of MD5 are very likely nullified by the I/O required.
Besides that, if you would reference it using the hash then there is no comparison to be made; you would only have a single file (this is about deduplication after all).
"[MD5 is] too slow to use as a general purpose hash"? Are there faster standardized hashes to compare files, that still have a reasonably low chance of collision?
Others have already mentioned keyed hashes (Message Authentication Codes) and non-crypto hashes, and one or two really fast crypto hashes that are more secure and usually as fast as MD5. But yes, as cryptographic hashes go, MD5 is certainly rather fast. That's mainly because it is uncomplicated and because it has a small state / output size.
As we found out, MD5 is so uncomplicated that it could be broken. Other algorithms such as SHA-256 and -512 largely rely on the same principles but are still deemed secure. Note that newer Intel and AMD processors have SHA-256 acceleration, so it is likely that they would perform similarly to MD5 if the hardware acceleration is indeed used.
As you can see, MD5 is almost never is a good idea, and many (smart) people still believe MD5 or SHA-1 to be secure under "their specific circumstances". They can often be proven wrong and leave the door open for (future) attacks on the system. I'd try to avoid it under any circumstances, especially if it is not used within HMAC.
What I also see is that it is defended because a system cannot be upgraded. MD5 has been under attack for years and years. If you still cannot migrate away from MD5 then there is something seriously wrong with the security of your system that transcends the use of MD5. If you're designing / programming or keeping systems without upgrade path then you're the main security hazard, not the hash algorithm.