If you look at the history of Google employees created the basis for JPEG XL [1], having it included in beta builds of Chrome and then removing it "for reasons", it's pretty obvious it wasn't pulled for technical or security reasons.
Obviously Apple didn't think there were significant security and implementation issues preventing them from enabling JPEG XL on over 2 billion devices.
The Chrome team has proposed a number of web features and APIs that Apple, Mozilla and sometimes Microsoft don't want to implement due to security and privacy reasons. Usually that doesn't stop Chrome from going ahead and shipping them anyway.
> (2) the benefit is relatively small -- it needs to provide a clear advantage over existing alternatives like jpg, png, webp, avif in some significant general use cases.
JPEG XL does provide advantages over existing alternatives—The Case for JPEG XL [2]:
In the past, new image formats have been introduced that brought
improvements in some areas while also introducing regressions in
others. For example, PNG was a great improvement over GIF,
except that it did not support animation. WebP brought
compression improvements over JPEG in the low to medium fidelity
range but at the cost of losing progressive decoding and
high-fidelity 4:4:4 encoding. AVIF improved compression further,
but at the cost of both progressive decoding and deployable
encoders.
We looked at six aspects of JPEG XL where it brings significant
benefits over existing image formats:
* Lossless JPEG recompression (20% on average)
* Progressive decoding
* Lossless compression performance
* Lossy compression performance
* Deployable encoder
* Works across the workflow