To be noted, the most annoying thing with Oauth2 and Google on Android is that you can't login with an email client or calendar with your Google account without your full phone to be associated with this Google account.
Also giving policy right on your device by this Google account.
That is totally insane in my opinion.
And you can't easily bypass that as oauth2 usage in WebView inside apps are easily restricted by Google on Android.
On a computer your are ok but not on an Android device.
To perform the oauth2 login, the app is forced to send the user to a specific Google webpage. There are only 2 ways to do that, load it inside a WebView within the app or send to an external url to be opened by the phone browser.
In both cases, Android (/Google) will capture that and use the "add account to Android" provider.
Now, let's suppose that you want to use your own custom WebView to avoid that, then the oauth2 page on Google server will perform a check against that and will refuse to load.
Officially "for security reason for the user".
The trouble with OAuth is to get a production client ID you must pass a third party security audit.. this is in excess of $20k and AIUI must be repeated periodically. Using a developer client ID is already heavily limited, and I have no doubt now that this ladder has been pulled up, developer IDs will see further restrictions in future.
IMAP/POP passwords have long defaulted to disabled in Gmail, Gmail survived 20 years without need for these new restrictions, I can't imagine attack techniques have improved and Google's internal technical staff have regressed so substantially that they are now essential. This change seems more motivated by creating frictions for escaping the Google vortex than anything to do with security.
Those things being separate is annoying to the average person who doesn't know the distinction between Google and Android (and Chrome for that matter).
And you can't easily bypass that as oauth2 usage in WebView inside apps are easily restricted by Google on Android.