Wait, are you saying the tools you use for JSON don't work for non-JSON data? ;-)
Chrome also decompresses gzip and understands TCP/IP, but it doesn't handle LZMA or SS7.
Sure, thanks to our cult-like following of bad principles, we've made support of on a pretty broken stack with lots of terrible consequences ubiquitous. I'd argue that's bug, not a feature.
So let me get this straight: you think we should all start using tools that may or may not even exist, and if they do exist, would require us to install a bunch of new stuff, write a bunch of schemas, and retrain, all so that we can solve a problem which so far boils down to "if you don't I'm gonna call your tools broken and you cult-like"?
I make a solid income solving problems that people pay me to solve. Why should I abandon that and devote my life to achieving 9% size and 4% availability time increase[1] that no client has ever asked me for?
And to be clear, it's not that I don't care about performance. It's that if my automated tests notice an endpoint loading slowly or if a client complains about performance, I can almost always achieve order-of-magnitude performance gains by optimizing a SQL query or twiddling some cache variables, which almost never happens by switching serialization formats. I have used protobuffers in a few cases, where profiling indicated it as a solution, but this has not been the norm in my experience.
The first optimization is getting it to work, and the second optimization is whatever profiling tells you it is.
But I think you're right that as long as we stay this course there's going to be more problems and so you'll be able to make more money solving problems that didn't need to exist.
You're absolutely right about the first optimization being to get it work. You're just discounting the reality is that you're making it far more difficult for that to happen.
In reality, now, JSON opens in everything from Chrome network inspector to Vim, and protobuffers/flatbuffers don't.