I believe the patent issue was by far the dominant friction for adoption in 2000s. On the NIST curve problem, well, maybe FUD, but evidently, they indeed backdoored the elliptic curve-based random number generator, so I would say some distrust is warranted.
Irrespective of the curve issue, ed25519/x25519 is superior and has other nice properties like not catastrophically breaking if you can't generate a unique random "k" for ECDSA as PlayStation discovered the hard way[1].
> like not catastrophically breaking if you can't generate a unique random "k" for ECDSA
How does that work? I thought that this vulnerability was independent of the curve that is used. Ed25519 has a bunch of other nice properties related to resistance to programming errors, but I never heard of this one.
> How does that work? I thought that this vulnerability was independent of the curve that is used.
The trick is that this value in Ed25519 is a deterministic hash of the private key and the message, which means that for the same message, the same value will always be chosen, and since the private key is part of the hash, for different messages the value is basically random unless you already know the private key.
Yes, the same trick can be used with any curve, and it will avoid the vulnerability; but for Ed25519, it's always been part of the specification so everyone does it that way, while for ECDSA it's a later addition (RFC 6979) and many implementations still do it the old way.
Irrespective of the curve issue, ed25519/x25519 is superior and has other nice properties like not catastrophically breaking if you can't generate a unique random "k" for ECDSA as PlayStation discovered the hard way[1].
[1]: https://youtu.be/DUGGJpn2_zY?t=2142