Flashbacks to DataTypes on the Amiga: https://wiki.amigaos.net/wiki/Datatypes_Library
I got my A1000 in late '85 and only had prior exposure to 8-bit home computers (C64, Atari, etc), CP/M and DOS (no mainframes, minis or workstations). I didn't actually use Macs or early Windows until the early 90s and it was shocking how backward they still seemed in some ways. I'd sort of the assumed the other major platforms were making similar advancements throughout by the late 80s and shocked to find out how wrong I was. It wasn't until the mid-90s that PCs and Macs felt like they mostly caught up on QoL and OS features.
That's how it works on macOS; the bundled apps (Preview, Photos, etc.) gained support for JPEG XL.
I saw this recently with Balena etcher. It's a firmware flashing app with about 10 buttons total. It's over 400mb because it's written in node and has an electron GUI.
Good jerb.
~$ du -h $(which dd)
76K /usr/bin/dd
$ du -h $(which pv)
116K /usr/bin/pv
sudo pv -Yo /dev/blah /path/to/your/image.img
My life improved measurably after I contributed that '-o' flag to pv and it then made its way into all my systems through regular OS updates :)
Another example clown app: the MacOS downloads of TuxGuitar, a Java app, used to just ship as a zip with a big jar in it. Now it ships an entire Java Runtime environment specific to your processor architecture. It's 480MB. Derp.
MacOS used to include Java out of the box, and then they stopped doing that. How else should an app reasonably behave to keep supporting new versions of the system?
What you're saying is it's the ideal kind of application for not obsessing over its background resource consumption, given that it's only going to be running for 10 minutes once or twice a year.
The thing is that it's still just a library, it just happened to be pre-installed. CGImage is just a helper in the Core Graphics library, not some magical "native"/"core" functionality in the OS that would be different than any other library with the same features.
An equivalent library for Linux (glycin for example), or per-format libraries like jxl-rs, are not "included in the OS", and tend to be the very same libraries one would use for Windows. If that does the trick on most platforms, then why have the maintenance burden of doing something different on macOS if all it does is save a few bytes on disk?
From Google's perspective, they would likely not want Chrome for macOS to gain support for jxl as the sole platform anyway, even if they are using CGImage and could decode it that way...
Browsers have also largely switched to handling most aspects of TLS and certificates themselves, despite there being OS libraries for those as well; the same applies to HTTP.
Shared libraries are a bad idea that is simply taking way too long to just die the horrible death it deserves.
Static linking is one and done, headache gone. People have large drives these days, so it's not a problem.
There are areas where the browser will dynamically link, but those are more OS-related than image and file format codecs.