Bureaucratic inertia. I've been hoping for years that it'll be certified. They've talked about Curve25519 and Curve448 for a while but no movement so far. My insider sources tell me there's opposition, but I have no clue why... either the NSA prefers weaker crypto or (more likely) industry wants the status quo because they fear competition from open source superior products like WireGuard among many others.
I feel like having a restricted set of algorithms in FIPS 140-2 is kind of the whole point of having things like AES in the first place. First you get everyone to agree on an algorithm, then you mandate that algorithm for your own applications. I don't expect them to budge from that, and I don't think it has anything to do with quality. At the point NIST certifies XSalsa20 as FIPS-compliant, they might as well rename it AESbis.
Industry prefers FIPS 140-2 because cryptographic expertise is extremely scarce and, prior to AES, commercial products were choc-a-bloc with broken hand-rolled cryptography. It's a rational decision to delegate selection of primitives to NIST.
I think FIPS 140-2 is aging poorly, but I think that's in part because all cryptographic standards are aging poorly; like, the whole concept: top-down standardization efforts with whole cryptosystems designed by committee have a very poor track record, and probably aren't the right vehicle to improve cryptographic soundness in the industry.
NIST SP 800-186 (Draft) has the curve definitions. But says only for Ed25519, not for X25519. They have a Weierstrass curve W-25519 that is isomorphic to Curve25519 that might allow using X25519 code, but that's way above my ability to judge. 'tptacek or 'jedisct1 or others will know.
The more productive approach is to work on convincing stodgy enterprises that FIPS is a bad thing (which it is).