At this point, in 2025, any substantial (non-degenerative) image processing written in C++ is a security issue waiting to happen. That's not specific to JPEG XL.
Nonetheless, we should really bear in mind how entrenched Cpp is. If you normalize CVEs by language popularity Java looks downright dangerous!
Why this quality poses security issues?
https://chromium.googlesource.com/chromium/src/+/main/docs/s...
No new code goes in that violates the rule, and ideally no code at all goes in that is both unsafe and parses untrusted data (regardless of sandboxing) and old code doing both gets replaced.
A giant pile of C++ can be used for rendering, not parsing untrusted data. A giant pile of C++ can sit behind a validator: a memory-safe JSON validator can vet a stream, before an C++ library deserializes it. Etc.
Google's position, on the other hand, has been a flat-out "no, we will not ship JXL". That's what has been met with criticism. Not an imagined reluctance to shipping a C++ JXL implementation.
I don't think it's irrational to be upset when a (near-)monopoly browser holds back useful features. Even if said browser is provided for free.