I don't disagree, but none of the comments given are otherwise false.
I've worked on real-time bidding software where the incoming protocol got changed from JSON to protobuffs. Just doing that made bandwidth costs go down majorly, CPU usage more than halved, and response times got cut.
When the question becomes "easy" vs. "good", always picking "easy" isn't very nice.
You were definitely working in a "very specific context"!
Also, I think that you have to consider how a company grows: JSON is simple to get started with. It's a good default - pretty much anyone can consume it very easily. As you explore your problem space and iterate and improve, you may realize it's not good enough. Fair enough - that's a good time to switch. But many people never reach that point, and will happily continue with JSON for a long time.
I've worked on real-time bidding software where the incoming protocol got changed from JSON to protobuffs. Just doing that made bandwidth costs go down majorly, CPU usage more than halved, and response times got cut.
When the question becomes "easy" vs. "good", always picking "easy" isn't very nice.