For Web APIs there are various motivations. For example, the Chrome side of Google sees native apps as an existential threat, so parity with native trumps most other concerns (IMHO they're exaggerating, but that's what they do). In terms of images they aren't behind enough to worry: AVIF is close enough to HEIC (both are based on the HEIF spec).

Incremental upgrades to CSS properties and selectors may take less code than an advanced codec library, and it's 1st party code, not 3rd party code. There's likely an engineering bias here: everyone prefers to write their own code and trusts it more. Dependencies are automatically seen as suspicious.

Some new flashy APIs like VR/AR, local filesystem access, WebAuthn, or payment request enable functionality that was not possible before. That's user-visible and adds something to the platform. On a high level a new codec is just images, like the platform already had, only a little bit faster. I advocate for web performance, but I also realize it's a tough sell, not a "wow" feature that can be used in marketing. Most sites aren't even optimizing their JPEGs yet, WebP has very little use, almost nobody uses AVIF, so lack of a better codec isn't a limiting factor yet for web perf in general.

In terms of "fire and motion" play, they can churn 400 minor CSS or JS properties to get 400 points in browser-vs-browser comparisons. JPEG XL just gives them one checkbox. Even looking at this super cynically, if they add a WebTrombone API that no other vendor wants, they'll get to permanently look better in "who's got more APIs" comparisons, but JPEG XL can be easily added to other engines. However, if you convince other vendors to release JPEG XL support, and add it to high-profile benchmarks, Google may be more interested.