So the first thing I want to talk about is the previously mentioned furball GZIP compression. I did manage to get a C# implementation together, which can be found here. This implementation is designed to be completely unnoticeable by both anyone using this class and also e.g. people using the editor -- I didn't see any need to make the compression configurable since I don't think there's likely to be any case where the compression is worse, unless the concern is CPU time, in which case I'm probably not the person to measure that (I can only run VS using a VM). I'm just not entirely sure what there would be to gain from such a configuration option. Regardless, writing the implementation was surprisingly simple, even if I had to spend some time debugging shenanigans like my Java implementation not writing the GZIP trailer or the written format version being misleading. (What's funny is I forgot to bump the max format version the first time I tested it, so Finmer thought it was itself out of date. Another fun moment was when I found out the format version of the furball being written doesn't necessarily equal the latest version, so I was accidentally writing format 21 furballs without compression. Fun times.)
Anyway, so for Core it's a decrease of 59.4% (down to 420 kiB -- small enough to upload to the forum!), which is different from my previous figure because apparently I wasn't writing the GZIP trailer. Regardless, I still think that's a pretty good decrease (and certainly blows any other optimizations I'm about to suggest out of the water). I've also tested some other furballs I have on hand: "DeepForest" decreases by 33980 bytes (69.1%), "Commission02.furball" decreases by 18726 bytes (60.6%), "Fetch module.furball" decreases by 9360 bytes (58.6%), and "Ollie.furball" decreases by 14362 bytes (57.9%). The average decrease for all of these is 61.1%, so that's probably around the figure that can be expected for most furballs. (Although this is only with a sample size of 5, there are simply not many furballs to test with, at least as far as I'm aware.) For fun, I also tested an empty furball (no assets, no dependencies), and compression did add 15 bytes to the output -- I think this is a bit of an extreme case though.
The next thing I wanted to suggest (or at least bring up): those funny 7 bit ints. They're already in use by strings (see BinaryReader), but they could also be used for other numbers like list lengths, byte array lengths, or enum constants. I've similarly tested this in Java and the decrease I got (for Core) was 1.2% (12404 byte decrease), which isn't terribly exciting (and combining that with compression makes the decrease almost imperceptible at only a 1108 byte difference). This doesn't take into account using 7 bit ints for e.g. creature stats though, but I don't imagine those would change the figure much. (I suppose I should also mention that 7 bit ints are bad for negative numbers since it ends up writing a full five bytes, or so I've heard.)
Another thing -- although this is arguably more error avoidance than any kind of file size optimization -- is about how lists are currently written using the optional serializable code path, meaning you could have lists with null objects. Requiring them to always be present and omitting the booleans results in a truly amazing decrease of 0.1% (1193 bytes), which is why I'm not suggesting this one as an optimization. Of course, a null object inside a list would probably only appear inside one of those questionable hand-crafted furballs, but it might still be worth doing this.
Finally, something I just now thought of (rather than like, three months ago): has OptiPNG (or one of its derivatives) been run over the item icons? It could reduce the file size of them somewhat (at the cost of muddying the git history slightly), assuming Finmer can read indexed mode (i.e., non-RGB) PNGs. (In fact, I just tested this, and it seems to shrink the Core furball by 10 kB, which isn't amazing, but it's free. Still don't know if Finmer will read these images -- though I assume it can.)
I'll probably submit a PR for the first optimization (assuming the current implementation is acceptable), but should I also include any of the others?