WebAuthN makes this a moot point though. All the auth is handled under the hood. There is no password or TOTP code to enter and yet in the right setup can be 2FA with minimal user interaction. The keys are stored resident on your device (something you have) and there is interaction to unlock them (finger/are or PIN/know). Best of all it's unphishable since the keys are unique per domain, so lookalike domains won't work.
(It seems like there's two different forms of this that Google has implemented. One form is done simply: when you log into Google, Google tells your phone to show a prompt, but this form is still phishable, because if you're using a phishing site while an attacker is proxying your login, they could still trigger it. The other form involves desktop Chrome talking over Bluetooth to your phone to verify what domain you're looking at. This method is immune to phishing domains like other WebAuthn authentication methods so presumably this is what they'd try to standardize. It does involve multiple moving parts so it's not too surprising it's not standardized yet.)
Because it's insecure. Because you as a user don't know which login attempt the prompt is for. This is especially bad when combined with applications with persistent connections that occasionally decide they need to re-up their credentials. It allows for attacks where you just spam someone with login requests until they either misclick or just get fed up.
Seems to me the MFA app could, with the approve/deny prompt, display the application the request is for.
If you delay the request of the MFA until after the password has been verified, then even a single "unexpected" MFA would be an indicator of the password having been compromised.
… and if it's insecure, well … MS is using that flow.
MS has that flow as an option and it can be disabled. In my job life I've already heard from regulators who want it off.
The actual fix is to move to webauthn where the user experience is excellent and the security is much stronger than any password flow could ever be no matter what stuff you pile on top.
There is a growing support for "Push" style authorization tools that more directly communicate between the devices. Up to now the tools have been mostly vendor-specific. Google has push notification authorization in the Google ecosystem. Apple has push notification authorization in the Apple ecosystem. Microsoft has push notification authorization the Microsoft ecosystem. The growing WebAuthn standards (for which the linked post is a Guide to working with them) are exactly the sorts of standards that are being built to increase inter-operability between vendors and trying to make "push" style authorization cheaper/easier/more ubiquitous on the web. (Those standards aren't 100% there yet for multi-vendor interoperability as other comments in these threads accurately nitpick, but this is still a giant step forward in that direction.)
Also, if your TOTP Authenticator app isn't already using your device's fingerprint or Face ID biometric locks, consider moving to a TOTP app that does. Most of the major ones do, exactly for that "trifecta" reason of layered security.
Webauthn is basically what you are asking for (thumbprint). It's basically Apple's TouchID brought across platforms and across the Web.
From my (maybe naive) POV as a user I tend to agree, it would be nice to have a standard for push-based authentication so that I can actually see when someone else has made it past the password prompt. Although email notifications would largely solve that problem (if more websites used them).
Because it proves that the user logging in is in control of a device that they've linked to the account. When you add an account to whatever app you're using (Google Authenticator, Authy, etc.) what it's actually doing is receiving a cryptographic key that it uses to generate the 6 digit code based on the current time. Without that key, the proper 6 digit code can't be generated.
I main difference here is usability. The current process is going into an app, finding+choosing the website from a list, tapping that website, manually copying from one screen to another, checking that you copied the digits correctly, then confirming. This is stressful and takes about a minute. A process where you just confirm a dialog, or use your fingerprint takes 2 seconds, and doesn't require the mental effort of memorizing and writing out 6 digits. If the people working on security can't see the enormous difference between the two workflows, then this is hopeless.
It's the same issue that plagues the security-minded people who think regular users will go around copying and storing each others' PGP keys.
The problem, IMO, is the lack of standardization. Okta has its own implementation, Google has its own implementation, etc. TOTPs in stark contrast are pretty universal and not that much harder to deal with, provided you have some way to backup and recover your TOTP keys (this is Authy's selling point, for example).
It is still a phone-based fenced authentication system, so it still sucks. But not due to usability.
Even better, use a thumbprint to authorize on the phone, to add one more layer of security. Then you hit the trifecta of verifying 1) something you know (the password entered on the website), 2) something you own (your phone), and 3) something about you (your fingerprint).