Hardware JPEG decode isn’t as valuable on today’s hardware. CPU decode with SIMD instructions is fast and energy efficient. It’s such a negligible part of battery usage that it’s barely worth thinking about for fast modern CPUs.

Even formats like H.264 are being dropped from some hardware decode engines because it’s so easy to do on CPUs now, as can be seen even on the Raspberry Pi 5. Many software stacks will skip hardware JPEG decode even when available because it’s extra maintenance and debugging overhead for such a little gain.

Progressive decode is a feature that is good in theory but rarely used in practice. If you’re concerning yourself with power usage and memory footprints, progressive decode goes in the opposite direction. Users also don’t like progressive decode as much as developers think they will as it’s often perceived as something being broken.

I think WebP made reasonable tradeoffs for the way images are actually used and delivered.

It also lost much of its quality advantage over plain jpeg, given the improvements in jpeg encoders: the jpegli encoder (from google's jpegxl team) has improved plain jpeg encoding significantly.

Most photo/design apps don't seem to be using SOTA jpeg encoders, though, so I think webp looks better in comparisons like OP's than it actually is. You maintain all the ultra-fast decoding of jpg when you use a modern encoder, too.

Is hardware decoding even commonly used for still image codecs?