The specification states that cloning should merely be included in the service's underlying threat model. E.g. you might well be able to log in from an authenticator that fails the "signature counting" step if it's expected that the authenticator would allow for backing up and restoring its stored credentials.
If an "insecure" authenticator reveals itself at enrollment, the only "unevenness" is that attempts to enroll it might fail, perhaps with a request to use a securely attested authenticator instead - you would never be locked out from any service after the fact. This is better than "cloning" a supposedly secure device and then failing a count check while trying to authenticate.
Yeah; being told "you can't use that here" for some sites is a pretty uneven user experience, wouldn't you say? Not sure why the scare quotes are necessary here.
