Characterizing Go like that would be too harsh. It certainly does integrate more experience than research, which is why Go is almost as often explained in terms of what it doesn't do as for what it does.

Go is not a research language (e.g. Haskell), it is pragmatic. I suspect a part of the design decisions of Go factored in training for people using that language. At a certain point, features that are alien cost more in training costs than they will gain in "elegance" or whatever.

I don't think the concern is training, but the complexity caused by how various features interact, and how hard they make to reason about code.

Go is designed so it is very easy to read and reason about what code does.

I don't know. Maybe it's because I've been mostly looking at Haskell and OCaml recently, but most of the more "researchy" features and languages I've seen aim to be easier to reason about.

Unlike most languages (including Go, I believe), researchy languages tend to have very well defined semantics based on well-understood math--really going out of the way to be easy to reason about!

That's what I like the most about it. All the context you need to understand a block of code is right there, but it's still less verbose than something like Java.

We all acknowledge that we spend more time reading than writing code but for some reason we still design languages that make writing it the priority.