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.
CPU decode efficiency most certainly was not the reason h.264 was dropped on the Pi
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.
It’s not always used when available. It can be a lot easier and safer while being fast enough to do it on the CPU. If the operating system has an image decoder path that will handle everything for you then it might be used (Apple hardware for example) but if you have to go out of your way to implement the API, common software will favor software decoding because nobody wants to maintain code testing branches for different hardware image decode platforms.