This defeats the point of 2FA if you can turn it off without that second factor. In your example, if you don't have that authenticated session then you're still screwed... so you must design for the worst case scenario. The risk of 2FA is losing a device, which is why a proper design has other safety backups, such as backup codes, or leveraging a combination of other accounts that can vouch for you and humans in the loop.
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).
Actually the newest version does allow export. For years it was true you couldn't export. But now they allow you to export. Thankfully.
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.