TL;DR it’s JSON-RPC over HTTP.
Any developer doing backend development can read the specification and understand it in ten minutes or less. It’s really short and clear. In my experience, the time it takes for an experienced developer from being introduced to JSON-RPC to implementing a functioning non-trivial API-endpoint can be less than a day.
No-one will ask you what these things mean or how they might need to change their infrastructure to get traffic to or from you.
Since both request and response bodies are JSON everything is very readable. Any request testing tool will be able to send requests to a JSON-RPC service and understand the response. You can even cURL them by hand.
Since the objects being passed around is just JSON it prevents you from involving specifics from the environment that the service is running in unless you really force it into the API. Makes it much easier to replace a service with a completely new implementation when needed.
Parsing JSON can be about as fast as figuring out the length of the string that contains it if you use a good parser. If you think this is too slow you either have a extremely specific problem you need to solve that a generic protocol like this will not solve, or you like spending time optimizing things that don’t need it instead of doing something more interesting.
If you think this causes too much data to be sent it’s probably that you are sending too much data and you should take a look at what you are sending. If you can’t reduce that just enabled gzip compression on the requests and responses, it’s HTTP after all.