Generally, if you want to restrict the user to use a particular authenticator, you need to own that authenticator. At that point you can have the attestation you are looking for. If you want Yubikey policy and behavior, you're gonna have to get your user a Yubikey.

The passkey provider vendors are motivated to serve their customer's needs (the end users, and secondarily enterprise deployments) over non-customer needs.

So Apple platform support (for example) will only send an attestation when one is configured via MDM. Your provisioned work device can indicate to work systems that it is in policy.

The compatibility-limiting risk, if it exists, is more likely from regulators putting their hands on the scale and pushing for security policies that would prevent synchronization and backup, and requiring attestations to make sure those policies are in effect.

Most "Passkey" branded approaches are portable. The "not portable" subset of Passkeys is primarily backwards compatibility with things like Yubikeys. That's also what attestation is mostly for, backwards compatibility with applications and Enterprises that still need "this is specifically the physical Yubikey I mailed this user" type keys, not as much Passkeys.

My dad didn't like iCloud Passwords because he still uses a Windows laptop and only recently has the iCloud Passwords app been good or all that useful. We settled on 1Password a few years ago and having 1Password on his phone and setup as his default password app means that iOS uses it as the default Passkey app as well. "It just works."

The vendors could use it to enhance lock in, but for the most part the vendors all seem in agreement that the rising tide safety to float all boats of Passkeys is worth investing in making them friendly, especially to non-technical users, and to some extent try to avoid direct lock-in.