Let's indeed take YubiKey as a representative expample here for hardware tokens. The YubiKey is unique in that it combines many functions that other tokens perform singlularly.
Regarding the backup issue about the house burning-down/flooding, the problem won't be solved by having pre-paired tokens, since people will just store them the same way. This can only be solved by having a (partly-)trusted third party and basically store the backup key with them (e.g. safety deposit box). This does present the problem of enrolling both keys though.
The YubiKey and most hardware tokens are DESIGNED to be unique, it's a choice, not a bug. Their whole premise is that each key/secret is completely random, unique, well-protected and only in your possession. If the factory could extract and import into some other device, then there are issues about regulations, auditing, trust etc.
The OTP, HMAC and OATH Challenge-Response function are programmable by the user and you can create backups as you please. The problem though, is that, if you store the condiguration somewhere, what's the point of hardware tokens? So that configuration must either be store extremely securely or you make your backups in a secure environment (airgapped, live cd) at the same time and hope you wont need to create more in the future.
The PIV and OpenPGP functions are, again, supposed to be unique. Best practice should be that, especially for signing keys, you generate and attest them on the device itself and they are unexctractable. If something happens to your keys, well, better you going through the trouble of creating new ones than someone impersonating you etc. As for the encryption keys, I hold the position, like others, that they should be generated on the computer and then imported on the token. But, I go a step further in saying that it is not necessary to perform the draconian key ceremony on an airgapped computer using a live cd etc. Basic fact: You decrypt your data on a computer using the key stored in hardware. If your computer is compromised and someone already steals the data they are after, then what's the point if your encryption key is secure or not... they already have the data. This boils down to: if you are worried that someone could steal the encryption key during generation and importation, they can very well steal the data when you decrypt it. So, on a reasonably trusted computer, you can have a backup of the encryption keys with reasonable risk. (The same doesn't go for signing keys, we want those always generated on hardware)
FIDO/FIDO2 function: The particular standard is designed so that it minimized exposure/risk in case of an attack/breach. The YubiKey 4, if I recall correctly, is seeded for the U2F function and it is static, so I guess that they could make duplicates at the factory. The YubiKey 5, and anything with FIDO2 is supposed to generate the key on-board and be unextractable, so to maximize security. If you could create backups, then there is no claim anymore for hardware-backed credentials.
All the above basically come down to any credentials/keys etc being generated on-board. As long as something is generated on-board, it would be counter-purpose to enable backups. This strict behavior is what makes such solutions strong authentication. The "inconvenience" presented far outweighs the benefits provided.
There indeed do exist some configurations that have backup capabilities but these are for very specific cases. Enterprise Hardware Security Modules (all except SmartCard HSM costing thousands of $$$) can do backups. Even in those cases, the HSMs that will hold backups have to be provisioned for that purpose in advance and "grouped together" so that the secrets can be transferred between them in encrypted form. Even in that case, someone has do do the backup in advance, not after the fact. This HSM backup is very similar to registering your backup FIDO2/OTP tokens at the same time for each account.
In all the scenarios, we notice that, for as-absolute-as-possible certainty that the secrets/keys on the tokens are not forged/duplicated etc, we HAVE to limit the backup capabilities (otherwise the secrets aren't hardware-bound anymore). Obviously they don't expect people to but expensive HSMs or have the knownledge to use the SmartCardHSM for secure backups (which are, again, done in advance, not the DKEK which aren't truly unextractable, but the XKEK), so the best reasonable way to implement all this and still be secure is to just have the ability to provision many tokens for the same service.
Some do mention the ability to do deterministic key derivation and duplicate devices. This is reasonable for e.g. BitCoin use because it's more acceptable to have a small chance of someone to steal the derivation passphrase, than having a destroyed wallet and losing your assets. But then their is the problem of storing the BACKUP of that passphrase. The same risk isn't acceptable for e.g. digital signatures. I don't want someone accessing my safebox and stealing a backup for my signature key.
In conclusion, great security requires some inconvenience. It is up to the user, bank, service provider to weigh whether the inconvenience offsets the security gains. Moreover, their could be a solution for backup devices that is less "inconvenient". Someone could e.g. provision 3 different SmartCardHSMs to share the same XKEK (Exchange Key Domain). Those devices can agree on a shared key without exposing it outside the device. Since all devices now use the same keys, the user can export ENCRYPTED keys from the "regular-use" device that can then be imported to the backup device. The benefit from this is that there is no need for the main and backup devices to be added at the same time for each service, only for the initial pairing. This solution requires much expertise though (above average users'). Having it done at the factory probably would have many problems with regulatory requirements, especially for digital signatures etc.