No, they're still rubbish. Even if you make them 256 bit, passwords are bearer tokens which are reused across multiple authentications, which makes them replayable (if intercepted on the client, in transit, or server-side), phishable, social engineerable etc.
> There is the very minimum amount of protocol necessary: one party asks for it; the other party provides it.
And that's unfortunately too little protocol to be secure for repeated authentications.
> [...] principally due to no longer being a shared secret [...]
No, that's not the most important part of WebAuthN. You could get most of the benefits, i.e. phishing and social engineering resistance, from running it as a symmetric encryption protocol as well. Asymmetric keys "only" make server-side storage less sensitive (in the same way that hashing does for regular passwords).
> The end user can pick his own software to manage his passwords, or none at all (a piece of paper in a wallet is remarkably secure) and the relying party to has no ability to approve or disapprove.
The same is true for WebAuthN! (The only counterpoint here is attestation, but that is no longer a thing ever since Apple and Google introduced cloud synchronization for their credentials.) The difference is that you now need at least some software, because the calculations are too difficult to do on pen and paper.
> I am concerned by how it reduces users to mere consumers, digital serfs to their technological overlords.
Then... just don't do that! There are several open source implementations FIDO for you to choose from at this point.
Attestation was most definitely removed from Apple's implementation.
For Google, there's still a (relatively obscure) way to get a non-synchronizing/non-discoverable credential (which is then by definition not a passkey!), which then supports attestation, but that's Chrome+Android specific and wouldn't work on e.g. Chrome on Windows or macOS.
They basically had two choices once they did introduce synchronization: Keep attestations around, but specifically mark synchronized credentials as "not strongly device-bound" (and risk existing relying parties not looking for that flag and drawing incorrect conclusions from receiving such an attestation statement), or get rid of it entirely.
I suspect that they opted for the latter mostly because it would require a lot of work with the FIDO and WebAuthN working groups to introduce that mechanism, not out of a selfless desire to avoid a future "big tech lock-in" (where everybody allows exactly Apple and Google passkeys, but nothing else), but I could definitely see the latter consideration also playing a role.