One very curious thing to me is that for the upcoming SHA-3 standard, Wikipedia lists the cycle timings for each hash method. I would have thought that slower hashing speed would be a good thing, but the faster the candidate algorithm the better it appears.
Perhaps the faster the hash is easier implement in hardware / less power for embedded devices?
Imagine an implementation of git fsck, which checks that all the files in the repository match their sha1 based file names. The less time it takes to hash each file, the faster overall checking time, so it is better to use a hash which is designed to be fast.
Writing hash functions is always a trade off between security and speed. SHA-3 contest has separate requirements for security, and they naturally want the fastest hash function that fulfills the requirements.
The complexity of a hardware implementation is also a factor.
He is referring to password hashing where brute forcing is an issue. For a cryptographic hash function, the goal is to be as fast as possible while retaining security. There is currently an intensive competition between the SHA-3 teams to produce the fastest implementations. Check out http://bench.cr.yp.to/results-sha3.html for more performance data on a range of machines.
It's not always the case that a hash that is faster in software is easier or cheaper to implement in hardware. For instance Skein is very fast on x86-64 but apparently is less competitive in low power hardware implementations.
I would have thought that slower hashing speed would be a good thing, but the faster the candidate algorithm the better it appears.
This is due to the confusion about the general purpose of a hash function versus the specific purpose of a "password hash"/PBKDF, which Jeff's article helps contribute to with it's loose terminology.
A general hash function should be fast as it needs to be invoked often.
Perhaps the faster the hash is easier implement in hardware / less power for embedded devices?