The below adds my understanding, which may very well be horribly wrong, of things. Corrections welcome as I try to figure this out myself!

> We have literally spend a decade getting people to use 2FA

This still supports MFA it just also supports SFA. Requiring MFA 100% of the time is a guarantee for something people won't use even if it fits security ideals better.

> Second, it looks like a blatant attempt to vendor-lock to me. The ability to sync passkeys across multiple devices is touted as a core feature

This one isn't as clean as I like either. There is a cross-device authentication flow, you can sign up multiple authenticators, and yubico has a backup authenticator proposal but none of these are necessarily ideal. I get not wanting to make the private key exportable for security reasons but if it's going to be allowed to sync on software authenticators over the internet I'm with you it should be able to sync between providers too. I'm not saying everyone should have to use cross-vendor sync I'm just saying it should be a capability.

> Meanwhile, syncing provides a security risk. Every synced device has access to all websites all of the time. If you lose sight of a device, an attacker also has access to those websites - and they might even clone the passkeys. This opens you up to attacks which are extremely hard to detect, and due to the passkey being shared between all devices also relatively difficult to stop.

You don't have to use external sync if you don't want and the standard still supports MFA on the passkey if you want but the truth is any solution that forces both of these 100% of the time will never see mass adoption.

> I am also seeing a lot of misleading statements surrounding its security.

I think a lot of it has to do with there being different levels of passkey store for different use cases. John Doe may want the convenience of just setting up a key on his phone and having it sync to all his devices for personal stuff but Jane Doe may need a hardware key with MFA for accessing the code repo at work and every option in-between. I don't think the security promises are misleading just maybe more complicated than one would wish because it's trying to be 1 way to cover all users and use cases not just "secure way" or "easy way for 1 particular device".

> Meanwhile, hardware token vendors like Yubikey point this out, but they do not see it as a threat as they are selling this synced implementation as not suitable for high-security environments - and rightly so. Luckily, the protocol has a built-in way to bypass this: the passkey backend can be asked for attestation, which in essence is an immutable certificate embedded in the hardware key, signed by the hardware vendor. If you want people to use a high-security passkey implementation, simply require attestation from a small list of well-known vendors - ideally only Yubikey of course. By hopping on the Passkeys bandwagon, they are able to erect significant barriers to entry for any potential competitors.

I don't know about "they are able to erect significant barriers to entry for any potential competitors" as the open passkey standard is specifically part of the next generation hardware key standard (FIDO2) rather than get locked into a proprietary hardware passkey format but I do agree it's the high-security way to use passkeys (as highlighted in my comments above). Not being able to export the private key, while annoying/disappointing in the cloud sync use case, is a hard requirement for the high-security use case so isn't an example of being there to provide lock-in. Especially with the ability to register multiple hardware authenticators for the same account.

> Finally, Passkeys provide a privacy risk. With traditional Webauthn the user provides a username to the server, and the server responds with a set of opaque blobs which the user's tokens use for further bidirectional authorization. With Passkeys, the server asks the token for their set of domain-relevant passkeys, which include the username.

I don't think the response contains any user identifying information. It does contain an opaque identifier the relying party can use to map to which user it was called the user-handle but that's not the user name it's a 64 byte sequence that can be mapped to a username if the other side already has it.