1. Kyberslash is mostly marketing. Some implementations (including the Kyber reference implementation, but *not* including the Kyber AVX implementation) had a non-constant time component. This is a meaningful CVE. It is not some fundamental weakness that should cause a panic. Note that the non-constant time implementations were caught ~2 years ago, prior to any deployment. So it was a sign of everything going "as expected", not of some new fundamental issue.
2. combining the cryptosystems, in most settings, is rather low cost. I would personally recommend it as a sensible default. It is not low cost in every setting though, for example in hardware it necessitates both a SHA2 and SHA3 impl, which is fairly expensive. So while hybrids are a sensible default, I would not go as far as to attempt to "ban" use of pure ML-KEM.
3. pure ML-KEM is much more "proven" than people are discussing. The core hardness assumption dates back to 2005, and has been intensely studied (the paper introducing it got a cryptography version of a Nobel prize (Godel prize), as did several follow-up works only achievable using that hardness assumption. The essential components of ML-KEM were proposed in ~2011. An extremely similar scheme (New Hope) was deployed experimentally in a hybrid in Chrome in 2016. Very concretely, the best theoretical attacks on ML-KEM take time ~2^cn for a c that has not changed in the last ~decade. Everything is as boring as you might hope.
On essentially any reasonable measure you could ask for, things have been "stable" with ML-KEM for ~1 decade. In the intervening years, a number of academics/companies have devoted a great deal of money on things built from even more sketchy hardness assumptions (I'm discussing the things underlying Fully Homomorphic Encryption). Even these have been essentially fine (I have some personal quibbles with some assumptions used, though they are technically dense, and are not relevant to ML-KEM in the slightest). So this is to say that there are natural "easier instances" of the thing underlying ML-KEM, and there still haven't been successful attacks of those instances.
Anyway though, the question isn't "should you use pure ML-KEM rather than hybrid". I would personally suggest hybrid unless it is extremely limiting for some particular scenario (and there are scenarios, such as hardware, where it is). The question is "should we standardize how pure ML-KEM TLS works, so implementors can create interoperable implementations?".
The answer to this should (clearly) be yes. ML-KEM is boring, high-quality cryptography. If a quantum computer appeared tomorrow, and only ML-KEM protected me, I would not lose any sleep personally. Efforts to delay standardization rely on "arguments" that do not match reality in the slightest.