All features can be abused.
The Go philosophy is more to leave out features that obscure the meaning and understanding of code (what is also known as "magic").
Also part of the Go philosophy is to not include any feature unless it is clear that its benefits are greater than its costs, and which might interact in unpredictable ways with other existing features.
In other words, the default is to leave things out, rather than to include them, the opposite of a kitchen sink approach.
However, operator overloading is very much needed for when creating user defined types that have arithmetic properties, such as bigint, or matrix.
As for the confusion about whether + means "add" or "concatenate", that is unresolvable. The D programming language deals with it by introducing the ~ binary operator to mean "concatenate". No more problems.
Although in D one can overload operators to mean any crazy thing one wants to, the consensus in the community is to eschew non-arithmetic use in the same manner that the C community has condemned:
#define BEGIN {
#define END }
I personally like overloading, but I think it's probably too easy to abuse, and I can see how it would cause problems with a team size larger than 5.
As far as I can see, whenever the Go team encountered a language feature that could possibly be abused, they always deferred to leaving it out. Whether that is good or bad I'm not sure we will know until we have years of experience with it.