I think decompression times would be a relevant criteria, but they're surprisingly not there...
Quite, and encoding speed, which is included, seems almost irrelevant
Did you know that, with the correct SIMD code, you can encode a 1080p bitmap into a 4:4:4 JPEG within 10 milliseconds on a typical consumer PC? Encoding times like this open up an entire dimension of new possibilities.
I do have a side project where I use libjpegturbo to synchronize a frame buffer between server & web client (i.e. 60 FPS real-time). HN may frown on using [m]jpeg for real-time applications today, but in my experience it has proven to be a very robust path. Bandwidth is really the only tradeoff (and it is a big one). This is the very last thing Netflix would want to do (short of sending RAW files to your TV), but it does provide some very compelling attributes in other areas such as streaming gaming.
Our networks are only getting faster over time. Intraframe video compression techniques are really elegant in their simplicity and resilience to motion-induced artifacts (as seen with x264, et. al.). They also can provide lower latency and easier recovery for clients (since every frame is a keyframe).
For real-time applications, I'd happily trade some extra bits per second to have a final result sooner. Especially if it looked better.