Hey,
I consider myself an image file format nerd, so thanks a lot for sharing this! FLIF was new to me.
I would like to share two important notes:
1. Unfortunately the flif.info website does not say a word about the CPU resources their current implementation burns when converting a, let's say, PNG to FLIF. It's pretty important to realize that CPU resources are even more valuable than storage space and network bandwidth. Sure, It's not really possible to come up with an exact threshold. But if, let's say, converting a PNG to FLIF saves 100 KiB, but takes a minute, this minute will never pay off.
If you follow the discussions on Wikimedia Commons, you will find this argument quite often: Downloading PNGs, optimizing them, and uploading them again is practically never worth it. Think of all the resources that are burned to do this: CPU time, download and upload, database storage and time, disk storage for the new revision, and not to forget the user doing all this.
Sure, your suggestion avoids a lot of this. But the CPUs involved will experience heavy load, both on the server as well as clients that need to recode FLIF files via a JavaScript library first.
2. Lossy file formats like JPEG should never be converted to lossless formats. This will actually decrease quality (over time). The problem is that the image data will still contain the exact same JPEG artifacts, but the fact that it was a JPEG (and how it was encoded) is lost. No tool specialized in squeezing the maximum quality out of lossy JPEGs can work any more. And there are a lot of super-awesome tools like this. Not only tools like JPEGCROP and such that can cut and even combine JPEGs without actually recoding them. There are also "JPEG repair" filters that know how to reverse the JPEG encoding algorithm and can squeeze out a tiny little bit of extra information regular JPEG decoders can't see.
This said, I'm all for adding FLIF to the list of allowed file formats!
Best Thiemo