While this statement isn't wrong, I find it a bit misleading. The good old Digital Signature Algorithm over finite fields has long been known to be fairly weak and has been banned from root programs for years. CAB Baseline Requirements v1.7.1 (2020) and newer explicitly forbids DSA keys from usage in publicy trusted certificates. So a DSA removal shouldn't come as a surprise to anyone - I don't know of any even half-modern application that takes security seriously and uses DSA keys.
It's important to recall here that DSA != ECDSA. ECDSA is alive and well and to my knowledge, no deprecation is planned by any agency.
Now we're mixing things.
First of all, FIPS standards primarily apply to USA government agencies and contractors. The worldwide PKI community is much larger and isn't entirely reliant on FIPS. That said, I acknowledge that many PKI systems (including Let's Encrypt and many HSM hardware vendors) are based in the USA and very much care about FIPS. That's fine, though the DSA removal doesn't mean that they are out of compliance. The (upcoming) standard says to use either RSA, ECDSA, or EdDSA. The CAB uses two out of three - that's the status quo, as we're not currently using DSA either.
Next, since you mention key exchanges: Nothing prevents you from using x25519, x448, brainpoolXYZ or whatever in key exchanges today. In fact all major browsers already do x25519. What's currently prohibited is the usage of Ed25519 (and Ed448) in certificates. That's not directly related to key exchange, but authentication.
About the security vulnerabilities: Well, what are your assumptions here? That RSA and ECDSA are both broken at the same time, while EdDSA is just fine? That's highly unlikely.
If quantum computers ever get powerful enough, all current algorithms are lost. That includes RSA, ECDSA and EdDSA - neither of them is safe against them. So if that's our main concern, EdDSA won't help us. A major flaw in both RSA and ECDSA algorithm classes is very remote, because they've been studied for decades. Now suddenly breaking them both at once sounds more like a movie than real world. Also, it's not like the CAB couldn't react if that were to happen.
That said, I'm definetly not against allowing EdDSA in X.509. However, my reasoning is a bit different:
- Ed25519 is faster than the comparable P-256 NIST ECDSA curve (source). The difference isn't gigantic, but on a small embedded system it can make all the difference
- Both Ed25519 and Ed448 are very reasonably designed, with all parameters openly documented, unlike their NIST counterparts. This reduces the risk of backdoors.
- Curve25519 is generally constant time by default (source). In many (common) implementations, no extra precautions are required to harden the base algorithm. This is unlike the NIST curves, where constant time requires some considerations. Constant time is required to prevent timing side channel attacks.
- The curve has no edge cases or special precautions to be considered when choosing or calculating curve points.
- Easy implementation with little room for errors.
- Security level is roughly identical to P-256 for Curve25519 and more or less similar to P-512 for Curve448 (theoretical security level is a bit lower here).
To sum up, Ed25519 (and Ed448 in a similar way) is superior to the NIST curves in all ways. So my question would be: Why not use the superior algorithms?