This is because the FIDO2 device actually has (finite) slots to remember e.g. credentials for funky-jokes.example so when you're at funky-jokes.example a WebAuthn API call can ask for those credentials and sign you in. No username, no password, you've presented all the credentials needed in one step. Whereas when keys are not resident the authenticator is relying on the web site to know (from your username) its ID, without being told the ID it can't do the authentication dance, so you will need to enter a username/ email address.
Resident keys are clearly a great idea in a phone (iPhone, Pixel, whatever) because it's not like gigabytes of flash storage will be exhausted storing credentials for the dozens or even thousands of sites you have credentials for.
It's less obviously a great idea for a Yubikey or cheap USB Security Key that maybe only has space for a dozen credentials. Maybe it makes sense to use it for that one web site you sign into every day, or to replace the main SSH key you use but if a Yubikey has 25 slots it doesn't make much sense for one to be "bush-jokes.example" which you last visited ten years ago...
So if you lose it the credentials are now essentially worthless (anybody who found it or stole it presumably doesn't have your PIN / fingerprints / face) and you should revoke them from sites where they were trusted.
Nothing prevents you from enrolling multiple FIDO2 resident key devices for a site, the site would store all the relevant credentials and you could use any of them to log in. I expect Apple's implementation notes for that demo last week tell implementers to allow multiple enrolment because some of Apple's best customers own an iPhone and an iPad and a MacBook Pro and expect to use all three.
But sure, you can use the second-factor-only FIDO behaviour on a FIDO2 key just fine, it's just that FIDO2 resident keys can offer a nicer user journey while still being secure.
You're proposing a TLS MitM (maybe plausible in a corporate environment that has this configured anyway) which downgrades the authenticator enrolment to have less protections, and then passing the resulting credentials to the real backend which will assume it has two factors without checking?
And later you steal the device so you can now use it without an additional factor because it wasn't enrolled using multi-factor anyway.
This would work as an element of the over-complicated schemes in an Oceans movie, but it doesn't feel very plausible in the real world. The skill sets to "Steal someone's iPhone" and "Obtain fraudulent Web PKI certs" don't overlap very much and this attack doesn't scale so it would need to be targeted.