> People say it's meant to replace login/password, not act as 2FAs.
They can, but they don't have to. It's up to the relying party (i.e. the website accepting them) to use them as a single-factor, two-factor, or just as yet another second-factor authentication solution.
Some websites make single-factor use contingent on the passkey's capabilities (e.g. user verification, only physical authenticators, only trusted-vendor physical authenticators through attestation etc). I believe Google does that and allows some users, based on these properties I believe, to use them as a single factor (the option is called "skip password when possible" in the account settings).
This is theoretically good for flexibility (one API allowing many use cases), but unfortunately quite confusing to users as the user experience can vary widely. One gripe I have with the API is that the default "user verification preference" is "preferred", which makes my hardware key prompt me for my PIN for every single authentication, even for second-factor usages that could just as well pick "discouraged" and use my as the other factor.
> There doesn't seem to be any support for federation of various keys by having them signed by a master key, as in PGP, so that I can actually prove on service X that I'm also the same user on service Y, thus being able to link or verify accounts easily.
That's correct – WebAuthN is intentionally a quite different model from GPG. That allows it to get by without key revocation, which would introduce a lot of complexity otherwise.
The specification allows something practically similar, though: Individual authenticators can be implemented almost statelessly, holding only a single root key that then derives (or unwraps) the per-credential keys from the key handle. It's a bit different from the federation you mention (all authenticators share a key rather than delegating signature privileges). But it's not commonly implemented, as far as I can tell.