The head of security for Golang, a google employee, was also part of the TLS 1.3 committee and in Golang, it's impossible by design to disable specific ciphers in TLS 1.3
The prick actually had the nerve to assert that TLS 1.3's security is so good this should never be necessary, and that even if it were, they'll just patch it and everyone can upgrade.
So someone releases a 0-day exploit for a specific TLS cipher. Now you have to wait until a patch is released and upgrade your production environment to fix it - all the while your pants are down. That's assuming you're running a current version in production and you don't have to test for bugs or performance issues upgrading to a current release.
Heaven fucking forbid you hear a cipher is exploitable and be able to push a config change within minutes of your team hearing about it.
I'd place 50/50 odds on it being a bribe by the NSA vs sheer ego.
Then all your performance tests can rely on the encryption and key exchange will always use the same amount of CPU time etc.
Histories biggest bug bounty is sitting on the bitcoin blockchain, if it were even theoretically plausible to crack sha-256 like that then we would probably know, and many have tried.
And that's exactly what we see - and every time it happens, the bitcoin community just laughs that someone must have been bad at key management or used a weak random number generator.
Except that has been the case in every instance thus far. The dev that lost his bitcoin last year was using arcane software, after a biopsy they found the library being used only had like 64 bits of entropy.