I just can’t get my head around this reasoning, it’s just as valid to ask for/return a “foo OR bar” as it is to ask for a “foo AND bar”. Any protocol that rejects that pushes that complexity elsewhere, somewhere less explicit.
I feel very strongly that type safety is of paramount importance in development, and "oneof" (and other similar constructs) in protocol design breaks fundamental ideas of type safety. It's a feature of the IDL that doesn't translate well to the actual implementing language, is not strictly necessary as the same thing can be accomplished through other designs that have an added benefit of being more explicit, both to the implementer and to the consumer.
1. It enhances readability
2. It would be a surprise to you: oneof actually enhances type safety. It is just lacking type system of Go where you cannot express the feature and thus loses type safety.
Let me guess: you are talking about types and type safety without learning type theory and type algebra. You are just throwing out 1 of the two basic building blocks of type algebra and sticking to your point even though everybody tells you how important it is.
Anyways it's ok if you want to be Go specific, this is totally fine.