Besides the other comments already here about code gen & contracts, a bigger one for me to step away from json/xml is binary serialization.

It sounds weird, and its totally dependent on your use case, but binary serialization can make a giant difference.

For me, I work with 3D data which is primarily (but not only) tightly packed arrays of floats & ints. I have a bunch of options available:

1. JSON/XML, readable, easy to work with, relatively bulky (but not as bad as people think if you compress) but no random access, and slow floating point parsing, great extensibility.

2. JSON/XML + base64, OK to work with, quite bulky, no random access, faster parsing, but no structure, extensible.

3. Manual binary serialization: hard to work with, OK size (esp compressed), random access if you put in the effort, optimal parsing, not extensible unless you put in a lot of effort.

4. Flatbuffers/protobuf/capn-proto/etc: easy to work with, great size (esp compressed), random access, close-to-optimal parsing, extensible.

Basically if you care about performance, you would really like to just have control of the binary layout of your data, but you generally don't want to design extensibility and random access yourself, so you end up sacrificing explicit layout (and so some performance) by choosing a convenient lib.

We are a very regularly sized company, but our 3D data spans hundreds of terabytes.

(also, no, there is no general purpose 3D format available to do this work, gltf and friends are great but have a small range of usecases)