Earlier quoted context omitted.
They're removing plain text auth because: a) password doesn't support 2nd factor. b) Most configurations keep password is on disk somewhere, often in plaintext. c) User configurations break on password rotation. Your tracking theory doesn't really hold up a) they know exactly who you are on your email client anyway as you log in and b) most users are logged in to their google/microsoft account anyway because of o375/…
a) is only relevant once, during setup; b) isn't fixed by Oauth; c) is by design, I'd argue. I support adding 2FA to email in some way, but I heavily dislike using browsers to do so. What's wrong with adding a simple challenge-response protocol for FIDO2/U2F USB drives? Or a TOTP popup if you don't have a physical security key? This can all be standardised without a browser ever touching the email client. We already…
Infrastructure to handle authentication on the web already exists. This is a massive benefit for providers and client developers. Whatever you propose does not. Good luck convincing big email providers to agree on a new standard like that.
GitHub alone has like 5 different ways to handle 2FA. Google has, I think, 3? Using a browser to handle this simplifies things a lot.
b) While it's not fixed by Oauth it greatly limits what can happen:
— First, you only need to store a refresh token that can expire and that expiration can be controlled by administrator
— Second, that token has limited scope: password provides access to entire account
— Third, it's clear where it came from — if token gets compromised, you will know where it happened. With password, it's unclear.