Their justification was more that adding it would be committing a lot of hardware and software vendors to support it which would be very expensive for not enough gain.
More accurately, their justification was based on discredited benchmarks (which used a fairly old-even-at-the-time version of libjxl and IIRC created by the AVIF team)... and the commit to remove support was created by a co-author of WebP who gives talks on WebP and is the primary contributor to libwebp.
The Chromium issue where they made this decision is full of "hardware and software vendors" (Adobe, Serif/Affinity, Krita, Facebook, Shopify, Cloudinary, Intel, Nvidia, the VESA DisplayHDR Chairman) telling them they're making a terrible decision and is one of the most-starred and most-commented-on issues of all time for Chromium.
You certainly have an opinion, but you do also keep leaving out facts that don't particularly support it, both here, and elsewhere.
"and the commit to remove support was created by a co-author of WebP who gives talks on WebP and is the primary contributor to libwebp."
Google also employs two of the co-authors of JPEG XL, who give talks on JPEG XL, and was were two of the primary contributors to libjxl.
The main authors of the JPEG XL specification are Jyrki Alakuijala, Jon Sneyers, and Luca Versari. Jyrki is a Googler. Jon is at Cloudinary. Luca is also at Google.
If you are going to try to come up with a silly conspiracy about this being WebP related, it probably would help if this wasn't the case.
Maybe consider that they do in fact have the expertise necessary to decide whether JPEG-XL is something they want to do?
I mean, seriously. You can disagree with the decision, but your argument that they have no idea what they are doing WRT to JPEG-XL seems pretty silly - the only company who arguably has any better idea would be cloudinary.
Phrasing this like "well Google must know best because they employ some subset of the people that worked on JXL" when the entire rest of the industry has been very overwhelmingly pro-JXL isn't very convincing.
Also my point wasn't "Google doesn't know what they're doing", it's that internal politics at Google are probably a factor in them basically being the only opposition to a standard that has been gaining support significantly faster than WebP or AVIF (both much older formats at this point) ever did.
»they do in fact have the expertise necessary to decide whether JPEG-XL is something they want to do?«
The problem is that they do have the people with expertise but those were not asked. For example, the AVIF team at Google does not have the expertise — they have proven that publicly (there was a AVIF vs JXL comparison thing that got put out) and later on an response they gave to Sneyers (the response got shared on Discord).
Hardware accelerated handling was one of the arguments used to oppose a WASM based implementation that sites could use at will to prove that there's demand for JPEG-XL support (and that the Chrome team provides, by the way).
No it wasn't. WASM implementations are simply slower than native support. No browser uses HW accelerated decode for AVIF images or JXL. I think Safari might use HW for JPEG, but that's it across all browsers.