There are four problems with just iterating md5 over and over, no matter how many times you do it.
Computing Power over Time
The first big problem here is that as written it doesn't scale over time to remain secure as computers get faster. What is secure today will be cracked in moments on tomorrow's computers.
Modern secure algorithms like bcrypt and scrypt have built in tuning so that the algorithm can be automatically adjusted to be slower as attacking computers get faster. Since bcrypt is also free and it's still just a simple function call for you, there's no good reason not to use it.
Now, you do have the start of a scaling structure built in to your code. It would be easy to refactor that to run the md5 hash an arbitrary number of times, such that you can tune it to be slower over time. But that's not good enough.
Designed for Failure
The second problem is that md5 is a fundamentally poor choice for a cryptographic hash because it was specifically designed to be fast. The purpose of md5 is for quickly verifying or comparing large files. To accomplish this, the hash needs to be able to be computed quickly and efficiently. This means the implementation and design goals of the algorithm are completely at odds with storing passwords. The chances that at some point we will figure out a way to compute an md5 hash that is orders of magnitude faster than what we can do currently is orders of magnitude higher than we will be able to do the same for sha1 or bcrypt.
The third problem is that hashing algorithms in general tend to degenerate as you iterate them. To understand this, take the original text supplied by the user. The conceptual size of this text is unbounded. There are an infinite number of possible values here. After we hash the text once with md5, we're down to 2128 number of possible values... still very large, but no longer unbounded. But let's cycle this again. md5 is good, but it's not perfect. Those 340 undecillion potential inputs will have some collisions, and yield a number of results that is close, but still somewhat less than, 2128. As you continue to iterate you'll find more collisions, until you eventually end up with a number that, while still large, is significantly less than the conceptual space you thought you were working with.
Finally, the fourth problem is some of your original potential inputs will results in cycles: value number 12345 hashes to 98743, which hashes to 67321, which hashes back to 12345, and so on. In other words, some inputs will cycle through the same small set of hash values, and iterating them further won't help. In fact, the more times you run the hash, the more likely a given original input will end up in a cycle.
This goes back to the design of md5. A cryptographic hash could be designed to minimize (not entirely eliminate, but at least minimize) the degeneration and cycle phenomenons, but it wasn't a concern at all for md5.
Any one of these reasons alone is enough to not use md5. There are other perfectly good options available, and they generally use the same interface, so choosing a different one isn't hard. In some platforms, it's as easy as changing an enum value you pass to some "createhash" function. Put all three reasons together, and continuing to use md5 is absolutely insane.