I'm curious how others handle this.
For corporate purposes, they're pretty decent. If one is lost or fails or whatever, they can get you a new one, because the company can quite-strongly verify that you are you - much better than your average website. A bank or something might also be reasonable.
For general personal use... I dunno. You really don't want to be locked out permanently if you lose the key, which tends to mean they degrade to your email security, and they're just convenience tools. Which is more than nothing! Convenience that emails you when it is bypassed is better than no email when bypassed! But it's very far from the security claims that tend to go along with these keys.
Personally I'd like these keys to be a "fast login" convenience, and for email-reset to be delayed by a day or three with an easy "revoke" button. It's exceedingly rare that I truly need backup access immediately, and allowing it all the time is definitely opening the door to bulk theft of accounts.
This gives me a pretty convenient list of sites I've set up the Yubikey with (at least for TOTP), since Yubico's OTP app lists all the sites I've used it for.
If a site only allows a single U2F key to be registered, I'd rather have a backup with TOTP over the better security of a single U2F key, so this arrangement works reasonably well for me.
If I’m enrolling the keys with a given service I make sure to add or remove all three at the same time so I don’t have to track which is associated with different accounts.
In this case though, full-disk encryption and TPM usage is the mitigation - provided the disk goes dead when anyone short of a nation-state tries to manipulate it, you're good.
My approach is to keep a list (a simple text file) of what services are used for U2F, and which keys are enrolled with it.
Most services ask or require you to name the token you enrol (if they support multiple tokens) - I gave the tokens names so they're consistent.
Now I have 2 ways to check - logging into a site, you can see what keys are enrolled. And as fallback, I can use my underlying text file and see which keys I enrolled.
You just need to make a point to check the file once every so often (at least first time you are near your backup key after having edited the text file).
I've seen some interesting approaches (on modifiable tokens where keys can be exported) where they configure a backup key as a mirror of the main key, but with the counter advanced forward such that using the backup will invalidate the regular (thus alerting you to the use of the backup by an adversary, as long as the service properly validates the counter).
I can't think of an easy solution to this (it is effectively the key distribution problem) without adding complexity (like manager software for tokens, and a Shamir's secret sharing style way to export a token's root key through SSS such that it can be recovered by a quorum of keys in an emergency). That breaks various aspects of the threat model though.
Perhaps there's a less complex way to do it though? Like having up to N persistent public key slots on the token, where public keys of your other tokens can reside. When registering, the generated key is also encrypted "to" those tokens, and sent as supplementary key handles. You'd need to add a pairing relationship to validate authenticity of the key handles, but I suppose it could work.
At the end of the day, so long as I can get access to my email and at least one bank, I'm confident that I can recover everything else in time. As such, if I have some recent account that isn't covered by that key I'm not particularly concerned.