It'll hardly take a couple of hours to write a simple login script, no?
I think you underestimate the complexity of managing your own auth. It takes a lot longer than a couple of hours to do it right. Testing alone would take longer than that. Authentication is one of the most important part of many apps, it's not something you should be skimping on or doing in a hurry. It's much better to pass it off to a third-party until you have the time and resources to do it correctly.
(here's a bunch of things you might not have considered: password resets, https, stopping spam bots creating accounts, users changing email addresses, etc.)
Although I also think that relying on one third-party auth solution is bad.
I would propose an intermediate solution: Implement the use of several auth solutions (e.g. like StackOverflow does). It takes some more time since ID management won't be as simple, but it's still incredibly less complex than implementing your own solution.
Frankly, I would happily move away from local auth solutions (except for critical services, e.g. banking). But I don't want to entirely rely on one account type either.
The friction of having to choose yet another password to sign up for an account is negated somewhat by using a FB/Twitter/Google-type oAuth/OpenID solution.
I'm a big fan of federated login and prefer to see it on sites where possible. But equally, I'm not sure I agree about making your site completely dependant on FB. Although if the app also requires social graph, then they're not really losing out all that much are they?
Completely agree, makes sense to do the simple thing first, then optionally add auth from other services later. Given that I recently nuked my Facebook account for example, having Facebook-only auth on a site effectively blocks me and others like me from signing up (never a good thing).