Before data travels over the network it has to be turned into bytes, and that translation is often the most expensive thing the request does.
JSON is human-readable and universal, which is exactly why it is verbose: every field name is repeated on the wire, and parsing costs real CPU. Protobuf compiles a schema into code and turns field names into numbers — much smaller, much faster, and unreadable without the schema. Avro carries the schema inside the data file, which suits large files and evolving pipelines at the cost of some size.
The right choice depends on who reads it. On a public API, outside our control, human-readability is a genuine advantage and JSON is a good default. Between our own services, where we own both ends, Protobuf or Avro buys smaller payloads and lower CPU in exchange for a readability nobody there needed.
Field numbers also buy evolution. A new producer adds active = 3; an old consumer ignores the field it doesn't recognise and keeps working. No breaking change, no coordinated deploy.
Convenience at a boundary is worth paying for. Convenience in the hot path is just overhead wearing a friendly face.