The linked blog post explains it. The spec can be implemented by open source software, but the upcoming (or now current?) update to the spec enables attestation, that is, it allows the auth provider to cryptographically verify which implementation the client is using. Under this scheme, auth providers can simply choose to no longer support open source implementations like KeePassXC, and since the spec authors have already claimed that KeePassXC is "non-compliant" because it doesn't ask for a PIN on every auth request, it seems likely that that would happen.
Then your version of KeyPass will not be signed and won't pass TPM checks and so the banking app will refuse to run unless you open the signed version?
Imagine using ssh-keygen, but it locks the private key in a vendor-managed secure enclave. You can't copy it, export it, rename it or do anything wth it.
I don't just imagine it, I do it, by using gpg-agent as my ssh-agent and using the private key generated by a Yubikey. Another way is to use tpm2-tools so only your laptop running your own signed boot chain can use the key. It is desirable to lock private key material in a physical thing that is hard to steal.
You can choose not to do this, and that's fine. Hardware attestation is dead because Apple refuses to implement it, so no one can force you to.
These days I would explore the TPM option, but I'm worried that has less legal teeth than a physical key if I'm in a law enforcement situation.
There's also practicality; I really, really don't want to tell my boss that TSA or whoever had access to the company git repositories and databases for X minutes or hours, and that's sidestepped by checking a bag with the Yubikey (wastes their time) or mailing it to the destination (needs a warrant).
