Why would you choose to slow down the calculation of a password hash?
The calculation is intentionally slowed down to make it harder for an attacker to brute-force the user passwords in case the password database gets stolen for example.
Because a hash function only works "one way", to get the password for a hash you have to hash random passwords until you find one with a matching hash. (Rainbow tables provide a tradeoff though).
Using GPUs it is possible to brute-force billions of e.g. MD5 hashes per second.
That's why hash functions like bcrypt or scrypt were developed to mitigate this problem by running slowly and in case of scrypt requiring lots of memory so it's unfeasible to compute the hash using GPUs.
For your "normal" application this will most likely still be fast enough, because you're computing a single hash only, so the performance impact will be negligible.
Possibly what is puzzling you is that it isn't clearer that... the calculation is not slowed down at all!
That is: there is no "faster" way that is purposefully ignored (not that we know of); there is no artificial "wait" shoehorned in the algorithm.
Rather, the calculation is designed to be slow. Or memory intensive. Or better yet, both. There is no road except the long and winding one to get the result.
This way, one calculation (that of the right password) is still very very fast. To honest users, nothing perceptibly changes. One tenth of a second or one billionth of a second don't seem to differ too much.
But one billion calculations (those to find which is the right password among a billion candidates - and in reality there are many, many more) will be agonizingly slow, guaranteeing that a "brute force" check of all possible passwords is doomed to failure.
So if we have a hashing algorithm that's too fast, we require not its first iteration, but its (say) millionth. If safe. Hopefully there is no way (that we know of) to jump straight to the millionth result; you have to calculate them all. And if this can't be done - we say the algorithm isn't secure (enough).
Password hashes are meant to be a computationally slow calculation because in the event that the password hashes are ever leaked it can significantly slow down an attacker trying to find the plaintext password.
If a password hash is slow to calculate, it makes brute-forcing a password much, much slower, which is going to add up over a large dataset or number of guesses. If it takes much longer, you gain that much extra time to deal with the breach.
With it, you can add a linear hardness to the dictionary attacks. I.e. appling a complex salting algorithm, you can make the computation need of the dictionary attacks n-times larger. For example, you can make it 1000 times larger.
In algorithmical sense, it is not very useful, because as we can see, the computing power grows mainly exponentially with the time. But it is still an additional layer of security.