Much more offensive (to me) is this gem from later on:
> Designing clever, binary and minimally repetitive protocols saves enormous amounts of CPU-time otherwise lost to compression.
Well yes, but also, and more importantly no. This is technically true - not compressing the data is more efficient in terms of computation per bit on the wire. But it is also wrong in a much more subtle way.
The advantage of using JSON (or an equivalent) and then compressing it down is that we inject a large amount of redundancy into the format. The CPU is taking that redundancy back out for us to save bandwidth, but we get to exploit it in much more valuable ways. The encoder/decoder are generic, simple and highly optimized. We can use them everywhere and trust them to work. This has value in itself, and it means that we can spend our limited budget of programmer time in optimizing other code where the payoff is higher. It means less time tracking down bugs in "super 10x programmer's one-off encoder that was only written for this specific application". And lastly, but my favourite - it means that when something goes wrong we have a hope of repairing the damage to the data. Because redundancy gives us options for error checking and recovery, while optimizing the binary format generally does not.
Also, if you want the format to really be optimal it should not be designed as byte streams (as low-level binary formats generally are) and instead should be a stream of variable-sized tokens that are fed through an arithmetic encoder.
The first half of this week I spent repairing data corruption caused by some of my code. Luckily there is a lot of redundancy in how I encoded the data (in a structure that is described in JSON inside the records) so I could write a tool that repaired the damage. I guess I'm lucky that I'm just a "farmer" :)