There's another scenario that matters here: an ordinary phishing website. Yes, about 15-20% of users never look at the URL bar and will type their password into any site that looks like the login screen regardless of how obviously bogus the URL is.

However, the server-side code for the phish now has a problem. The user may be protected by two-factor authentication. To handle that case, the PHP script or whatever needs to step through the login process in the same way a browser would. Google have tech that can make it very, very hard for this PHP script to do that (it's called BotGuard). So the next move is that the phishing site needs to use an embedded browser to try and evade BotGuard's detections. Then it can obtain the necessary codes to trigger the 2-step verification challenge and intercept the number sent to the user's phone, and finally complete the login to obtain session cookies before storing them and redirecting the user to the real google website (so they don't suspect anything).

There are ways BotGuard can detect embedded browsers apparently, as they specifically say they will ban CEF and embedded internet explorer. But if you do that then people who use the embedding features to make their own browsers are out of luck. It's really tricky because it's hard to see how you can get critical mass for a new browser if you're limited to OAuth (which is meant for APIs). You'd have to get in touch with Google somehow and ask them to whitelist your browser. If they're sharp and fast about that even for new or hobby browsers then maybe this won't be so bad. If they get jammed up in product management bureaucracy and don't whitelist browsers fast enough, it could turn into an anti-trust issue for them.