> But the actual software being developed requires either spying device (aka smart phone) or worse, biometrics.

No. Not even remotely true.
In the simplest implementation (from what I remember, just in brief summary) of a U2F hardware token there are two storage components:
- Master key (or rather 'initial key', which is only generated once)
- Global signature counter

For 'registering' a U2F token for an account on an online service, the token is presented an RP ID (generally the protocol and domain part of the service authenticated to), and from that RP ID it derives a new private/public keypair (in-memory) from the stored master key, using a key derivation function, and presents the generated public key to the service. All these cryptographic operations happen internally on the token.

Then when authenticating to the same service, the RP ID is presented again along with a challenge to the token, the same private/public keypair is generated in-memory again, and creates a signature of the RP-provided challenge as well as the current 'signature counter' state, and returns the resulting signature (as well as the current 'signature count' it was signed with) to the service, while also internally incrementing the signature count by 1 in it's internal storage.

The service verifies if the signature matches up with the public key on record, and also makes sure that the 'signature count' is greater than the last time authenticated to the service. Otherwise if the signature count is the same as last time, or less than, then it would indicate a replay attack, and would be considered invalid.

In this scheme, there is a different public/private keypair for every service, yet within storage, it only has to remember one key, and has to keep a signature count.

Meanwhile, in further evolution into FIDO2, there's the addition of device attestation, whereas there's a separate private key and certificate burned into a batch of 100,000 tokens/devices of the exact same model, that is ONLY for a service to be able to verify the model and profile/capability of the token, as attested by it's manufacturer.

Each hardware vendor has their own root certificate that certifies the hardware attestation certificate burned into the token or cryptographic component. Hardware attestation is only relevant to appeal to government and financial sectors that require hardware certification, or to have authenticators from specific vendors or profiles. Hardware attestation is just an additional option presented that's not required for implementation in online services, it's just meant for organizations that want tighter control, for example: the US DoD could prohibit a DoD system from allowing some government contractor from registering a Hauwei-brand authenticator for their account. That's the intended use-case it's targeting with that addition. The attestation information is only presented upon registering an authenticator to an account for a service--and not used for any subsequent authentications.

As for biometrics and other components, that's all just internal to the implementation of the authentication token, of whether it wants to sign a challenge or not, and just being an advertised feature presented in the hardware attestation certificate, whereas it NEVER sends biometric information in any response.
https://fidoalliance.org/fido-technotes-the-truth-about-attestation/