Bernstein is a co-author on NIST PQC competition submissions that didn't win (Classic McEliece, which just had a huge new research result, and Streamlined NTRU Prime, a lattice cousin to MLKEM).
When CRYSTALS/Kyber was selected in the NIST competition instead of SNTRUP, Bernstein didn't take it well. He claimed malfeasance by NIST and sued them for allegedly hiding documents.
Meanwhile, over the subsequent years, the world has continued turning on its axes. CRYSTALS/Kyber is now ML-KEM. Because many cryptography engineers and other security people think there's a lot of urgency to getting PQC deployed (because of harvest-now decrypt-later [HNDL] attacks), the IETF got a move on standardizing hybrid ECDH/MLKEM TLS 1.3, which is what everyone uses.
Nobody at IETF has ever to my knowledge even hinted that anyone should avoid hybrids. There is a standards-track RFC defining ECDH/ML-KEM hybrids.
There are environments where hybrids are problematic. You won't likely use any of them ever. Some of them occur within the US Government, and some of them are on highly constrained platforms (people seem to disbelieve this is ever really a thing but I once gameovered a smart meter because its RF protocol only had like 16 bits of counter space for CTR).
Because of this, there is also a proposed informational RFC --- not a standards track document --- that documents what pure MLKEM looks like in a TLS 1.3 setting. Bernstein's entire argument is that this is an NSA plot.
For discussion on Bernstein's objection to that IETF draft see article from ~month ago, "NSA and IETF: Fairness":
The mere publishing of an RFC has customarily been treated by developers as a stamp of approval from the IETF.
The NSA, contractors and their fans argue that simply adding a "RECOMMENDED=N" in an obscure section of this draft will somehow prevent said implementations in deployments.
However, as an example, Canada's NSA equivalent specifically requested the draft to be published so that they can use it to support their poor choice in deployment of solo ML-KEM nation-wide.
While ML-KEM may be sound, significant bugs in implementations in the wild continue to be published.
To be clear, CRQCs do not exist today.
ECC is battle tested, proven, and is used today.
It makes no sense to delete working cryptography and replace it with potentially buggy, non-battle tested implementations of new cryptography for a threat that does not yet exist today.
Instead, you fight HNDL [1] with hybrid which preserves the safety of today, and hopefully also, tomorrow.
No serious security person should be recommending otherwise which is, perhaps, why some may question the motives of those that are pushing for solo ML-KEM.
[1] Harvest now decrypt later