The difference is that: 1) this is accessible and usable by anyone running a modern operating system+browser. mTLS client certs need to be provisioned which is one of the major reasons why it is only used in enterprise settings. And 2) passkeys and WebAuthn are privacy preserving features. You can't track users across different websites with FIDO2 devices (mTLS does not preserve your privacy at all). This was one of the core principals that went into the design of FIDO(2) from the beginning.
Client certs as implemented on Gemini and IRC are self-signed. They are enrolled on the service after they're created. They don't need enterprise level capabilities. In fact, even the creation of these certificates are automated on many clients (eg: Lagrange Gemini browser, soju IRC bouncer). You don't even think of them as certificates. They're considered as identities.
And regarding the privacy. You can deploy as many certificates/identities as you want on multiple accounts and sites. It's not possible to track them across sites or even across accounts, since there is no CA involved.
Passkeys are indeed similar to that approach. There's no CA infrastructure, so they can be considered "self-signed certificates" (though they do not present as certificates, and currently cannot be used for TLS to my understanding, though I don't think there are technical reasons you couldn't wrap them in x509 metadata and use them as such it's just not a core use case), generated per-service, and enrolled as they are created. Passkeys add a couple enterprise features back in than just "raw self-signed certificates" in the form of optional "attestations" designed in a somewhat privacy-preserving way to prove the type of device that owns the key and in deeper enterprise modes the serial number of the device.
