You don't need to weak cryptography to work towards that end with passkeys.
For key pairs that can be transferred, it's no different than the threat of password managers stealing your keys to the castle. You just have to trust the cloud and your entire hardware and software stack your password and passkey manager run on, and/or that nothing in that stack gets swapped out without you noticing.
Similarly, I've yet to see a hardware security key that you can verify doesn't have backdoors compiled or soldered in. All the cryptography in the world doesn't matter if a government/whoever can just pop your Yubikey in a machine that does whatever magic incantation is needed to dump your keys. That magic incantation can even be secured with strong cryptography to ensure only the US government/whoever can use it.
And of course if you're truly paranoid you can get a FPGA and implement a hardware security key on that. The overall security posture would likely be weaker, but you could be confident, hopefully, that nobody has put some kind of backdoor into the hardware you designed yourself to run atop a generic array of logic gates.
You'd have to choose your FPGA judiciously. The truly paranoid see the attack surface area of 100 GB of black box libraries needed to synthesize designs and appreciate the possibility of gateware trojans.
While I think choosing an open source stack is important, can you imagine how difficult it would be to inject a remote exploit into ARBITRARY hardware your code didn't know in advance?
Nice, last time I looked the Solo Hacker Edition was completely out of stock.
Looks like the Solo HE lets you load your own firmware on to it, but it doesn't let you load your own signing or encryption key to ensure firmware updates are trusted. Apparently the Solo HE can be flashed once permanently by overwriting the bootloader, though.
The non-HE versions of the Solo 1 and 2 will load new firmware signed by Solokey.
Earlier this year I looked into this and remember finding out that it was either the Solo 1/2, Somu or one of the Nitrokey products that, while shipping with a secure element, didn't actually use the secure element.
Not even that, I just assume that in a few years, anyone who has a few thousand dollars to hand to Cellebrite will have access to devices that can crack security keys, just like they can give Cellebrite some money today for devices that can hack phones, tablets and computers nearly instantly.
The applet source code I linked above can be configured to use your PIN (not stored on the device) as the keying material to AES256-encrypt all the credentials stored on the trusted element. The PIN may be up to 63 bytes long, and the derivative used for keying is 128 bits.
If you think some company in the future will have the ability to somehow "steal" the contents of the device's flash, you'd still have to climb the mountain of explaining how they could then break the encryption the open-source software already - before they got hold of the key - applied to the flash contents.
Just to make sure this is clear, the security key at rest is not storing your credentials. It is storing AES256(key=<PIN>, value=<credential>). It is not storing the PIN.
You only need to trust the hardware to implement encryption correctly, which you can - of course - verify yourself. It's not realistic to say that the pre-encrypted values might be secretly stored somewhere else: there just isn't enough space on the device to do that.
No passkeys are based on whatever the best crypto is -- for example in a world where quantum computers are practical then they'll be using a quantum safe algorithm.
Spy agencies, law enforcement, and criminals would all much prefer people use easily guessable and/or unsafely stored passwords. Those are both easier to discover, easier to brute force, and easier to intercept (specifically all you need to do is intercept a password once as it's definitionally not based on a single time exchange).
Or to grab your phone with a 4 digit pin and unlock every device you've secured with a passkey. At least previously your bad password was probably longer than a 4 digit pin.
