There’s a difference between logging into Google via 2FA and having subsequent interactions not require the 2nd factor, and turning off 2FA without a reconfirmation. You don’t want maximum usability in disabling your security mechanisms.
Google is intentionally leaving this route open to lessen the impact of a lost authenticator. Probably this is a very significant cost savings for them -- although I don't know what their account recovery policy is for "lost" 2FA.
I'd say one risk factor here is that if someone is able to piggyback your session (e.g. CSRF) specifically into the 2FA Settings API, they may be able to get your 2FA disabled in a way that meaningfully exposes your account to a wider attack.
Another risk is similar to why you should require a password to be re-entered in order to change a password. The user is already in an authenticated session, and yet, it's still considered best practice to prompt for the existing password at the same time. This can't merely be as a second layer of CSRF protection, right? If your CSRF is broken, fix your CSRF.
I would assume the theory is to prevent an opportunist attacker with a small time window of access to your session (keyboard) from getting longer term access to your account.
Particularly for accounts that have long-lived sessions that don't have to use 2FA very often because of the cached session, you might not notice for quite some time that 2FA is no longer active.
As with most things in security, it's a double-edged sword.
you know that google asks your password when you want to change your password right?
on both cases, password change and 2FA disable, it is asking password (but not 2FA)
So I think when you are logged in it is 1st factor, 2nd one is password. No need for 3rd one.
An attacker disabling and then promptly re-enabling 2FA (thus locking me out of my own account) is a different problem altogether.
If so, then the bad guys can disable 2FA on your account without you having to prove the 2FA token. [Edit: but nowadays, at least you get emails and device notification that it has happened]
Traditionally, security teams have thrown up their hands and said - with malware installed, all bets are off.
I'm not sure I agree with that assessment these days, with state sponsored 0-days and trojans. I think that OPs sentiment is right, and Google and others should require 2FA reauthentication to remove 2FA, especially for their 'titanium' security tier.
BTW, it's interesting to ask what is the downside of requiring 2FA re-authentication: I believe the reason to not require 2FA is historical: When it was initially rolled out, a bunch of people tried out 2FA because it was the new coolness, got somehow lost and immediately wanted to disable it, but are not able to (lost token, have no idea what the heck they are doing etc) and get stuck. Since 2FA account recovery is very manual and expensive, Google probably doesn't want to take that hit.
Google's own 2FA app (Google Authenticator) doesn't even let you export your keys.
Though I tend to use U2F. With Yubikeys and other U2F keys. I use my Yubikey to store a backup of the TOTP (Authenticator type) codes. I also set a password and touch required to generate the codes.
You can use your password AND that authenticated and still valid session or device to do the reset.
Google gives you options with your free account.
1) No 2FA
2) 2FA with insecure methods
3) 2FA with security keys and authenticators.
4) Advanced Protection Program
5) Paid account options with additional options / controls.
that's not true. You need to think of a threat model. 2FA still successfully prevents attackers that do not yet have a session to connect to your account.
So it is still a clear net benefit.
What it does not prevent, is attackers downgrading your account from a session that already exist. At this point it is easy to argue that if an attacker has this kind of access then the only thing you can do is add 2FA to all critical actions, not just removing 2FA (that would be the least of your issue), but every critical action you can do in the app.
For example if the app is a bank, and wants to protect against these kind of attacks, then they have to prompt 2FA every time you want to want to send money (at least).