First off, MD5 is said to be insecure. Sure, but only for some purposes. This very recently appeared on the security stackexchange website[1]: Why does some popular software still use MD5?
In the SHA-1 chapter he mentions that you can truncate SHA-2 outputs if you are concerned about storage space. No! It may be entirely safe or even desirable in the case of SHA-2, but how can you be sure? It might very well be designed differently. Never invent your own crypto. Another recent thread on the security stackexchange mentioned[2]: "The fact that you need to ask this question is the answer itself - you do not know what is wrong with stacking these primitives, and therefore cannot possibly know what benefits or weaknesses there are."
Then the article goes on about SHA-2: "Sha-256 should be chosen in most cases, including hashing your user passwords" Oh God no. Use bcrypt, scrypt, PBKDF2--I don't care. Don't invent your own crypto. Hashes work great for storing passwords, but hashing algorithms aren't invented for password storage! Hashing algos are supposed to be fast (see the SHA-3 competition, they were looking for algorithms that were especially fast on hardware implementations as complement for SHA-2).
And then lastly, testing only a single implementation (the one in .NET) is hardly a good comparison. It doesn't matter much how much hashes you can do per millisecond, especially since secure password hashing algorithms are supposed to run slowly.
All in all, have a look at this if you want to know the real answer: http://security.stackexchange.com/questions/211/how-to-secur...
[1] http://security.stackexchange.com/questions/33108/why-does-s...
[2] http://security.stackexchange.com/questions/33531/why-improv...