When generating non-resident/non-discoverable credentials, many authenticators will use a source of randomness, an internal secret and possibly the name of the requesting origin to generate a private key, and export either a seed value or a wrapped version of that key in a 'credential handle' during registration. You have to pass that handle back to authenticate someone, which the authenticator will process and check to see if they were the one that issued it. Such credentials are only usable for secondary factors, because you need to know what list of registered handles to pass to the authenticator, which means you will typically need to know who the requesting party is.

Web Authentication and CTAP 2.x added the notion of discoverable credentials, which do not require such handles and as such are usable as a primary factor for authentication. A site can simply ask into the void "do you have any credentials for example.com" and potentially get back an answer. These necessarily require state.

Several of the platforms do not want to deal with the security ramifications of exporting wrapped keys, and simply generate and store keys even in the traditional U2F case. This is actually why the terminology was changed from 'resident' to 'discoverable' in WebAuthn L2 and CTAP 2.1 - a non-discoverable credential has the old behavior where you have to supply the handle to get back a response, but there's no guarantee that credential won't be resident in some state store of the authenticator.