To clear up a possible misunderstanding from the presentation: security keys on Prime are derived deterministically from the master seed. The keys themselves are not random. Your instinct that this is the right approach is correct, and it is how Prime already works.
Where backup remains necessary is more specific. For each registered credential, the device stores metadata that is not derivable from the seed alone: the relying party identity, user information, signature counters, and the derivation indices used. Without that metadata, the device has no record of what credentials exist or how to map an incoming authentication request to the right key. The seed gives you the ability to derive any key, but not the knowledge of which keys to derive.
Your Ledger comparison is a useful reference point and worth unpacking properly, because the two approaches involve a genuine architectural tradeoff rather than one being strictly better.
Ledger’s implementation (following SLIP-0013) is fully stateless. The credential ID that the website stores and presents during authentication contains a nonce, and the device uses the master seed plus that nonce to derive the signing key on the fly. The device retains nothing between sessions. Restore from seed, and the next time any registered site presents a credential ID, the correct key is reconstructed automatically. No backup needed for credentials.
The tradeoff is that a stateless device has no awareness of its own credential state. It cannot show you what is registered, cannot let you manage individual credentials, and cannot support passwordless login flows where the authenticator presents credentials to the site rather than the other way around. That last point is significant: the modern FIDO2 standard introduced discoverable credentials specifically to enable passwordless authentication, where you tap the device without entering a username first. That capability requires the authenticator to store credential metadata, which is exactly what Prime does.
Prime is built toward full FIDO2 support, including passwordless flows. That is the reason for the on-device metadata storage, and it is a deliberate choice rather than an oversight. The backup dependency is the cost of that capability.
That said, the underlying concern in your request is valid. A design that embeds enough information in the credential ID to re-derive the key from seed alone, even without the full metadata backup, would meaningfully reduce the consequences of losing a backup. It is a reasonable thing to want, and your feedback on it is noted.