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.
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.
https://github.com/johnezang/JSONKit has a few interesting corner cases, for example.
It's easy to consume with Javascript, which is where most JSON probably ends up.
Ultimately though, something I've learned over the years is that you can either "go with the flow" and do things the way most people are, or you can try and do things your own way. Unless you're Microsoft or Google or something though, mostly, you don't have enough resources to do everything your own way, so you have to strike out on your own only where it really counts. Erlang does that in a number of places already, for sensible reasons - it's part of what makes the language so good at some things. However, fighting JSON is likely one of those Don Quixote battles that's not really going to get you much outside of some very specific contexts.