As for other services beyond Gmail, there's not a great ecosystem for exporting.
For one-off exports, Google Takeout is decent enough, although there's a lacking ecosystem to import the big .mbox files back to an email provider.
What's so "insecure" about "per-app passwords"?
I ask, because I've lost the past 5 years of my life to building and running an internet-facing OAuth2+OIDC IAM system and I'm (still) an active contributor back to the open-source OIDC framework it's built-on. I grok the grants and flows and I've got the blood-pressure to show for it (and developed a healthy opposition to SAML); but despite all of that, I appreciate simple solutions to problems where there's a very real risk of over-engineering - and especially when a simpler system (like per-app passwords) can make a system overall more secure because there will be less mistakes being made, even if some clinicaly-dry technical assessment mathematically proves the complex solution is more "secure" by some measure.
///
> although there's a lacking ecosystem to import the big .mbox files back to an email provider.
Everyone I know (okay, just a handful of ("normal") people) who has done this ended-up converting the .mbox to a PST for Outlook and copied it over to any other machines they have; it's an archive mailbox after-all, so just put it in read-only mode and don't worry about data-synchronization issues.
Kinda ironic that Gmail's credibility was/is built on ex-Outlook users looking for something better, only for Outlook to be the refuge (and last resting place?) for hundred-gigabyte-sized e-mail archives.
[1] https://answers.microsoft.com/en-us/outlook_com/forum/all/re...
But a mistake WILL be made, because humans are fallible, and mistakes with a long lived bearer token can be extremely damaging, and can remain latent for a long period of time (e.g., password accidentally saved on disk and "deleted").
With proper OAuth, a lot of mistakes can be practically harmless (e.g., access token accidentally saved somewhere).