Presumably, bcrypt is something that has been vetted by crypto experts, whereas your idea is just some random thing you thought up. Maybe you personally are a crypto expert and know for a fact that your plan will work, but the vast majority of people aren't. A packaged solution like bcrypt that doesn't give the developer enough rope to hang themselves (and their users) is a much better idea.

The idea is a developer will just do:

  passwd_str = bcrypt_string_from_password(passwd);
  db_store_password(userid, passwd_str);

and just be done with it, rather than having to decide between ROT13 (kidding), hashing, salted hashing, HMAC, etc. A couple years ago I thought applying SHA1 to a password before storing it in the DB was perfectly fine. Later I discovered that it was better to use a salt. More recently I've discovered that both of those approaches are flawed. Fortunately I've never written a large-scale application that deals with storing passwords, but I'm sure there are many application developers like me who would write much safer password storage routines if they didn't have to be the one to select an algorithm.

Now, I'm not saying bcrypt is the answer (I know nothing about it beyond what I've read on HN), but that's the general problem with your hypothetical proposal.

Nothing enormous; that's basically what PBKDF1 does. cperciva might correct me on this, but IIRC there are some minor concerns, addressed by PBKDF2, which is a slightly more complicated construction, about the iterated hash function degenerating into cycles. I don't think there have ever been any practical results exploiting this. PBKDF2 is just as good a choice as bcrypt, and a better-supported one.