Workflows already exist where an app shows an embedded login page. Users have already become accustomed to it. A malicious developer trying to phish in that flow will just substitute a self-hosted or local simulation of the Google login form. Worst case, you pretend there was an error and punt the user to "backup login" in a real browser to now blow your cover. This won't prevent such scams.
If they had made the decision several years ago, they might have been able to say "We've never and never will supported this type of login flow; if you see it, it's a scam" and managed expectations on a going forward basis. But now you're stripping functionality without a clear user-facing notification that embedded logins are suspicious. Is there even a reasonable way to convey that info to most potentially impacted users today?
Of course, that doesn't solve the problem of dividing the world between "real" and "embedded" browsers, but that's another story. Again, if this wasn't a regression, it would be more forgivable. I can accept that the full Google experience won't work on other unsupported environments (say, the web browser packed in with OS/2), but it's not like those worked yesterday but not today as a policy choice.
That doesn't work because Google login is multi-step. Just stealing a password isn't enough, then you need to log in with it. They have anti-hacking systems and two factor auth to stop that.
If the app uses a webview to connect to its own brand of oauth, that isn't affected.