It's also not just about being faster than the network because the browser is probably simultaneously doing page layout, javascript parsing, image decompression and a ton of other things. Also more time spent decoding images is a drain on the battery.

Focusing solely on compression stats can be misleading, it's a balancing act. For example, I'm not sure being 0.7x smaller than PNG is much of a win if FLIF ends up being an order of magnitude slower. Perhaps it is still a win but it needs a bit more nuance in the analysis to reach that conclusion.

Also it wouldn't really be a fair comparison to show this slowly maturing format's decoding time versus that of formats that have had decades of time for people to research and find the best ways for decoding (even hardware tailored). You're comparing the heavy weight champ against the up and comer with a lot of promise. FLIF would get pretty beat up in that comparison, but perhaps only because it isn't even finished yet, and thus hasn't had the time to reach that level of efficiency. From having used it, and played around with it, it seems to be pretty fast. Fast enough that people wouldn't notice a perceptible difference between it and other common formats. I think the current decode time is about 20 MegaBytes per second. Which is faster than most people's internet, and considerably larger than most people's images (on the web).

Once it's bitstream has been finalized and it starts to get some use, we'll see decoders improve their performance. The initial plan was to lock the bitstream for a 2016 release, and then in a year or two release a new bitstream with further improvements. Similar to GIFv87a (1987 version) and GIFv89a (1989 version with improvements and new features). However this may have changed as the FLIF 2016 release was set for late December, then February, and has been pushed back again.

In due time we'll see more accurately how the format compares to the existing champs in terms of performance.