In all seriousness, it feels like go's reputation of simplicity is at odds with its design. Instead of making a simple and highly generalized core from which anything can be composed, it has a specialized, familiar core that engineers are comfortable with.
When I take this question further, I begin to wonder why we even use text syntax for programming. What if we just had a graph structured programming "language" that is edited indirectly through different projected syntaxes that aren't necessarily monospaced text. Almost like lisp, but translated into different frontend languages, potentially graphical. (Maybe off topic but whatever)
In fact, since macros reduce the noise in the "language" a library implements, I've generally found that macro-based libraries are somewhat easier to learn than libraries in other languages.
A carefully designed library that introduces a small set of coherent concepts can make good use of powerful syntactic abstractions and result in readable and succinct code.
But application code that implements a large number of one-off requirements is far harder to read if you cannot rely on fixed semantics of basic syntactical elements.
The usual response to that is to say that we shouldn't restrict the features available to good developers just because bad developers might abuse them.
But this argument is flawed. If you read syntax that can be overloaded then you have to account for the possibility that it actually is. It's the possibility that creates the mental burden, not the fact.
I think the solution is for languages to provide a basic set of syntactical elements that cannot be overloaded and are sufficient to write all code. Additionally, there should be optional syntactical elements that can be overloaded even to the point of creating DSLs.
The important point is, there has to be a local cue that tells you whether or not you have to watch out for redefined semantics.