This naively assumes that your entire userbase uses those services and would like to attribute their Google (et al) account with your service. This may not always be the case.
Someone has to store the passwords, it would be good if there was a way you could be assured your data at rest was safe.
If you believe your userbase will object to Google/Twitter/FB, use BrowserID.
Personally, I never feel particularly secure when typing passwords into text boxes on random PHP forms. On the other hand, I feel fairly confident that the folks at FB, Google, Twitter, and Mozilla know how to store a password and secure their infrastructure.
On the other other hand, I don't really like the idea of 1) tying all my accounts to Google (what happens when I want to get rid of my Google account? Or my Google account gets locked?) or 2) having Google / FB be aware of other websites I log into,
What's the browser support level of BrowserID at this point? How does BrowserID transfer between the different browsers I use? Can I log in using BrowserID on my phone?
It's good. I use it (dual-auth with FB) in a production system (https://www.voo.st/) and it works great from every browser I've tried so far, including iOS and Android.
The biggest UX issue is currently the up-front email roundtrip for new accounts. In the long run this experience will improve considerably when primary identity providers support the protocol directly. In the short run it's still not bad.
Someone has to store the passwords, it would be good if there was a way you could be assured your data at rest was safe.