ML-KEM encaps/decaps is very fast, as fast/faster than EC. It's large, and adding EC does not meaningfully affect the size, but it meanfully affects encaps/decaps time.
Don't buy the argument, this stuff is simple enough that we can formally verify and audit it very carefully.
Additionally, NIST had the foresight to derandomize all the algorithms, so we can now check e.g. what a correct implementation will produce on particular seeds. This is a big deal because a bunch of e.g. ECDSA bugs, such as biased nonces or reused nonces, are trivally caught by such tests/derandomization.
I used to be pro-hybrid but I feel much more on the fence about it nowadays.
ECC software can have flaws too but I don't think anyone seriously suggested hybridizing two different ECC implementations, for example.
Why don't we use hybrid RSA and ECC then? Or hybrid AES and ChaCha20?
Software bugs is a weak argument for a new hybrid standard, and doesn't justify the additional complexity.
In his defense, ECC is unusually fast compared to both RSA and current PQ
ML-KEM encaps/decaps is very fast, as fast/faster than EC. It's large, and adding EC does not meaningfully affect the size, but it meanfully affects encaps/decaps time.
Don't buy the argument, this stuff is simple enough that we can formally verify and audit it very carefully.
Additionally, NIST had the foresight to derandomize all the algorithms, so we can now check e.g. what a correct implementation will produce on particular seeds. This is a big deal because a bunch of e.g. ECDSA bugs, such as biased nonces or reused nonces, are trivally caught by such tests/derandomization.
TLDR: the bugs are going to be elsewhere.