Why not just have that compression format be PNG filtering + DEFLATE? PNG filtering is extremely simple and is probably implementable in two dozen lines of code. It's nothing compared to the complexity of the entropy coder.
At that point you might as well just be a subset of PNG, which is nice for interoperability anyway.
I'm not really an expert on the matter, but couldn't PNG filtering be implemented in the same way, i.e. as a filter just like Farbfeld? This way it would keep the same composability, and be used with other formats too.
Considering there are no stand-alone implementation of these, I guess the author simply went with what achieved the highest compression ratio, regardless of speed.
But it would be interesting to see if a complete ecosystem can pop up around it sooner or later, especially given the renewed interest in arguments between "the unix way" and other philosophies.
You could use PNG filtering in other formats, sure. I don't know why you wouldn't just use PNG at that point, though. The only difference between this and PNG is the chunk format to encode IHDR, IDAT, and IEND (which is really easy) and a handful of extra bytes in the IHDR chunk to specify truecolor mode and so forth.
The truecolor-with-no-extra-chunks subset of PNG is incredibly simple.
At that point you might as well just be a subset of PNG, which is nice for interoperability anyway.