> You can't detect all breaking changes automatically. A field can subtly shift semantics on an API level, yet that breaks a workflow for some downstream consumer somewhere.

That is what aip.dev helps with. Following these style guides makes it hard to have ambiguous meaning of a field in an API. Linting APIs is something buff provides.

This isn't a "catch 100%" thing but this is more close to a "catch >XX% of mistakes" which is good enough if it cheap.

> OpenAPI and other API description languages give a clear an unambiguous description of an API that can auto-generate clients just fine.

The last time I used OpenAPI it was very verbose. It wasn't anything like writing code (something I am good at). It was more like writing a large config (something I'm bad at). Protos provide a code-like view on APIs. This is just preference though but I like it.

> Binary JSON/gzipped JSON is frequently very space efficient too.

My assumption is that parsing JSON will require more CPU than protos and much more than flatbuffers. More so when you factor in gzip.

> Using tracing and other advanced techniques require the right knowledge to use, and I don't think it's that common in smaller orgs.

Taking something that's complex and making it easy for people to use sounds like a business prop. Is tracing something people don't do because there's no value or because it's hard to use?

Basically: you don't want to use protos for any one reason. It's a whole ecosystem that makes many things magically better.