I mean, it may well work if you have 2FA enabled (it depends on whether you can set up two different 2FA options and force the login provider to use the stale one) -- but you do have to hijack someone's account which is indeed considerably harder if they have 2FA enabled.

Security can roughly be described as "the inability to do something surprising, measured in dollars." The surprising thing here is that under some circumstances you might feel like you have "reclaimed your account" (by disabling their 2FA method and resetting your password) only to find out that you have not (because an authentication session dependent on the stale method and password is still "live in the system" and can be used to log in to your account). The distinctive thing is that this can be done for the low low price of just keeping a website open in a spare tab, but it requires a previous vulnerability to have paid the high price of hijacking the account in the first place.

What's interesting is that these sorts of it-makes-surprising-things-a-lot-more-surprising scenarios is that there are kind of two different equally-valid measurements of their security implications, one high and one low. In a total-cost-of-attack sense, yeah, you have to incur the cost to hijack the account in the first place and this means that if they're doing things right this is an "expensive" attack and therefore the service is still secure. But in a marginal-cost-of-adding-this-attack sense, this is a very cheap attack and points to the login flow having a deep security vulnerability. So it's contextual whether the system is secure or not.

That of course probably won't be news to anyone who works in security, I suppose -- they are used to security not being a monolithic thing that everything is easily classified as yes or no. (Like, if you have seen the different attacks on hash functions you already can appreciate "is this secure?" depends on what you're trying to do with it -- and that's bog-standard everyone-in-appsec-knows-that knowledge.)