Earlier quoted context omitted.
I want to avoid having to fetch my backup key every time I want to setup a new account. The backup key is kept offsite and thus inconvenient. It's offsite because that protects me from fire or other such catastrophic events. This is what keeps me preferring password based security because I can backup my encrypted password database offsite with ease. Everything else provides hard path to recovery.
> I want to avoid having to fetch my backup key every time I want to setup a new account. The backup key is kept offsite and thus inconvenient. As stated, you can have as many backup keys as you like. Thus you are not limited to two keys. Buy one more key. Keep one off-site and two on-prem. Rotate them once in a while to keep the off-site one fresh.
That does not solve anything unless the backup keys are enrolled to each and every one of the services you use. Adding more backup keys and storing them more and more securely just makes it harder to be sure that you've enrolled them all to the latest service.
This is not an issue if users are explicitly allowed to enroll "virtual" soft authenticators that they can back up and restore as they see fit, but that's an additional requirement that comes at some compromise, since some services might instead want to ensure that you're enrolling a non-cloneable credential. (E.g. your physical bank or non-remote employer, that can easily verify your identity via additional means if needed to restore your access.) The WebAuthn spec allows for both models.