Why would you use this "poor man's approach" over bcrypt or scrypt? My understanding is that these two work on a very similar concept (work factor) and are free to use.
If a randomly clobbered together and unvetted system is compliant, but bcrypt isn't, that just goes to show how little FIPS140-2 compliance actually means. (as if everybody didn't already know it's worthless)
Nonetheless, some projects mandate use of FIPS 140-2 hashing algorithms, and afaik bcrypt is not one. So if you find yourself on such a project, bcrypt is not an option on the table.
I'd be happy to find out I'm wrong.
I can think of one reason: Lack of the available libraries on a particular platform.
This is why I mentioned it. It provides improved time guarantees for your users with out needing another library.
bcrypt is open source and ported to a range of operating systems. I cannot imagine getting it up and running on any system would be too difficult. It would probably be wiser to to spend the time to get bcrypt (or another standard scheme) working rather than coming up with some custom scheme which probably hasn't had the same level of thought put into it.
Because building your own square-shaped wheel is more fun than talking a walk over to your friendly neighborhood wheel store and buying a round one?
Because we all know rolling your own in the crypto world instead of deferring to the experts never leads to catastrophe!
You assume those are the only two choices, I was considering that in some environments these might be the only two choices when I asked the question.