For any format you can store an image at multiple resolutions/quality-levels and a responsive app can download the one with the size/quality it wants.
jxl probably saves an incremental amount of storage, which is nice, but storage is not usually the dominant cost of anything. So this is still an edge case.
The point is not needing to store multiple copies of an image. You can simplify the back-end if you serve the same file to all clients.
You’re assuming that the high-quality original is still available. If the JPEG is all you have, then losslessly recompressing it is the smallest file of the highest quality you can get.
That's what I mean by "tweener" solution. You care a little about quality because you don't want to lose any more that you already have lost in your jpg, but not so much that you're keeping track of the high-quality originals. It's not nothing, but it's also not a big deal.
> Lossless JPEG recompression (20% on average)
Lossless JPEG recompression isn't that valuable because it's a "tweener" solution. If you mainly just care about image size, you can live with some loss and can recompress jpegs using existing formats. Or if you care about size and quality, you can recompress from high-quality sources using existing formats. lossless jpeg recompression kind of fits in the middle somewhere... you care enough about size to go through the trouble to recompress, but you don't care so much that you will use high-quality sources and you care about quality enough that you don't want to lose quality when recompressing, but again not so much that you will use high-quality sources. So it's not nothing, but not great either.
> Progressive decoding
A solution to a vanishing edge case.
> Lossless compression performance
Explains why you might want to use jxl in your workflow but that's not a browser concern.
> Lossy compression performance
This sounds good, but is it enough better over existing formats to justify a new one in the browser? I don't think it's clear cut.
> Deployable encoder
Obviously, existing formats have deployed encoders.
> Works across the workflow
Not a browser concern. Note that even if you use jxl across your entire workflow, you're still going very typically have a publishing step for images where you find and use a level of compression/quality appropriate for your project. There's not really any particular difference if the general image format type has changes at this step or not.