If the site insists on UV (User Verification) rather than UP (User Presence) a device which has no way to verify the user should reject that.

If your site insists on the device providing a broad identifying signature (the specification says devices classes identified this way ought to consist of 10k+ devices, and in most cases a manufacturer will just identify particular models, like OK, this the model we made in 2019-2021, now we're re-tooling to make the newer model lets give it a new identifier) and the user agrees (I always refuse if asked, the documentation advises you just don't bother asking) to provide this, then you can see OK, it's a Yubikey Model 6J, I think that's (delete as appropriate) fine / not fine. This is obviously a large piece of extra maintenance work, hence it's advised you should not do it.

You wouldn't transfer a passkey to your YubiKey. You would enroll it as another device that can be used to login. Like right now on my Google account I have an iCloud passkey and a Windows Hello passkey since iCloud can't sync a passkey to Windows (yet).

Hypothetical political journalist just lost both his Yubikeys when his office and home were both targeted. He still has an off-site backup of his passkey. How would you envision this working?

I'm unfamiliar with the particulars of passkeys, but with hardware tokens I've used before, you'd log in ASAP an unenroll the keys you've lost custody of.

So this is basically the same thing like ssh keys?

Exactly. But with some added security.