What threat model concerns you here? Anybody who'd be able to disable 2FA already has access to my logged in Google session on a trusted device. The game is over.
Right. Instead of debating the headline, this is the real question. The current behavior is that "someone on a 2FA authenticated session can disable 2FA". OK, so what?
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.
Pragmatically, I believe the threat is that someone has managed to install some malware on your phone/computer/... you are 2FA logged in.
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 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.