> The guarantee that key is never cloned unknowingly even machine fully compromised isn't in this new model.
True, that was my concern with the new specification as well. But I believe the main problem will be account takeovers, not malware.
> Because if you can export or sync the key, then malware probably also can if your device is compromised.
Not necessarily. There are ways to still keep these keys only in secure hardware while allowing synchronization if the secure hardware supports service-provider mediated attestation.
HSMs usually support a similar process, where keys can be copied to a different HSM by the same vendor, preserving all of their usage and authentication restrictions (i.e. only the same set of authenticated and authorized users are able to use them).
This conceptually works by e.g. a new and old device, or a service-provider side HSM-secured backup and a new device, establishing a secured channel, attesting their state to each other and then copying the credentials over that secured channel.
By necessity, this includes the service provider (or at least their HSM code) as a trusted party: They are the one that ultimately gets to decide which new devices get added to the synchronization set, and under what circumstances (running a recent hardware and software version, multifactor authentication, providing a high or low entropy shared secret).
Of course, all of this also vastly increases the trusted computing base, and this might well not be appropriate for high security organizational environments.