As a producer of the response, if I didn't care about being understood, I would use a made-up language. As a consumer, you may care about understanding my response, but you cannot do anything about it.

Hence the design. The producer coming up with a made up language that makes sense to the producer, but probably doesn't make sense to the consumer — especially when you have many different consumers with very different needs — is far more problematic than the producer providing an abstract representation and allowing the consumer to dig into the specific details it wants.

As with everything in life, there are tradeoffs to that approach, of course, and it might be hard to grasp if you come from languages which different idioms that prioritize producer over consumer, but if you look closely everything about Go is designed to prioritize the needs of the consumer over the needs of the producer. That does seem to confuse a lot of people, interestingly. I expect because it isn't idiomatic to prioritize the consumer in a lot of other languages and people get caught up in trying to write code in those other languages using Go syntax instead of actually learning Go.