Attestations are "Enterprise-grade" specs that mostly only impact "Enterprise Passkeys".
Apple has made it very clear that they will never support Attestation on consumer hardware. So long as Apple is a leader in consumer hardware, consumer apps can't rely on any sort of cryptographically-signed Attestation data being meaningful.
> I don’t know what a “relying party” is, so I’m not sure exactly what this threat entails.
This is most of what is wrong with your argument, I think. "Relying Party" is just fancy security lingo for "website or app that accepts Passkeys" (someone that relies on a passkey, as opposed to provides one), as in any or all of them. There's no "spec" for blocking clients. What you saw wasn't really a "threat" that a banhammer might come down. There's just the million different ways that websites can implement them, and some of them may reject Passkeys without certain metadata or attestations. But you will find out quickly on sign up with that key. It's kind of like some websites blocking passwords without a symbol in them and others don't care if you like symbols or not.
That said, it's also a lot like blocking users based on User Agent string. It's a wild west out there of different mixtures of metadata and/or attestation, some Passkeys just outright lie or pretend to be like the key of someone else. Apple has made it clear their consumer-grade Passkeys send the bare minimum and not much else. If a website wants to support average iOS users, they can't rely on any fingerprinting from Attestations and they have a bare minimum of other key data.
But there will be (already are) "Enterprise-Grade solutions" from companies like Microsoft and Google that want to keep corporate networks "extra secure" and will require you to use Genuine Microsoft Passkeys for Enterprise 2025 Edition Pro or Google Workspace Passkey Manager for Google Authenticator on Android Ultra Secure.
It wasn't a "threat", I don't think, it was an acknowledgement that things are complicated.
Also complicated, the "threat" wasn't even directly about Enterprise-grade (cryptographic) Attestations but the "Passkeys can be both first and second factor and Passkeys can claim that they did that" feature. It's mostly a simple boolean field "checked the user had a second factor" and the open source tools can mostly just lie and there is no way to cryptographically verify that. Apple does lie the other direction (so far as I've seen, Passkeys always use the biometric unlock on iOS, but the keys themselves don't state that they did). It is part of both sides of the ongoing debate about whether or not Passkeys count as one or two factors, websites are making both choices today, and no one can agree, and the spec doesn't help and can't actually threaten anyone to comply with "my Passkeys are always two factor".