The leak of the password's correctness here is ultimately not problematic as it acts as a tripwire and a surprise for the attacker. In fact the platform can take action on the user's behalf and lock logins with that password until the user confirms it was them trying to login via a separate channel (if you used Google 2FA this is what they do). It also protects accounts without 2FA because it becomes risky for the attacker to just try a password list they find. Maybe they're lucky and get in, or maybe the account has 2FA and you've just burned the password by trying it and alerting the user/platform about the compromise.
If it were the other way around with 2FA first, you would have no way of knowing your password is compromised somewhere. Even if the attacker knew the right password, the would not attempt to login unless they defeated the 2FA. Now you have no early warning system, and it becomes all-or-nothing: attacker get full access or they wait silently.
To sum it up: The login is no weaker if you put 2FA after password auth (same amount of compromises needed to get in). 2FA after password can leak password validity information for a short duration of time (on the scale of 15mins), but it also sets in motion an alarm that invalidates that password when an attack is attempted. 2FA after password also provides a tiny bit of extra protection to non-2FA accounts by letting them hide among the 2FA ones.
(Also, the original purpose of 2FA after password is to cut down costs for the platform back when SMS 2FA was the only 2FA. This is largely irrelevant today with TOTP and FIDO2 relegating SMS based authentication as the least secure option.)