I don't think the Go team has any problem understanding anything. I think they have different subjective goals for a programming language than many critics, which leads to a feature set which includes some things critics would leave out and excludes some things critics would prefer (like generics.)
I think Go has gotten fairly decent traction because there are roles for which real programmers find it reasonably well suited compared to existing alternatives, and I think that, not the previous work of the creators, is what drives attention to it.
OTOH, I think Go's period in the sun is going to be a lot shorter than, e.g., Rust's unless we see a Go 2.x that addresses some of the "not in the Go 1.x timeline" things with Go fairly soon.
I do agree that the problem relates to language goals, but their poor choices of goals to pursue do demonstrate a lack of understanding. Their stated goals are frequently solutions that don't really address good use cases. Take for example fast compilation time: the stated use case for that goal was compiling Google's massive C++ code base, which took too long to reasonably compile on a dev machine because of template expansions. Refusing to add generics is an idiotic solution to this problem:
1. Generics aren't templates, and are in fact a solution to this problem. They don't expand at compile time.
2. The long compilation times are indicative of deeper problems: an over complicated code base that should be refactored down, and lack of modularity which would allow partial compilation (only compile the changed modules).
3. Removing generics creates new problems with increased bugs and duplicated code. It's trading compile-time for development time, which has historically rarely been a good trade.
4. Even if this is a legitimate concern for Google (which I still don't think it is), it's not a legitimate concern for 99.9% of projects out there. How many projects actually have millions of lines of code that can't be factored down and modularized? If this is really Go's target then they should admit it's a highly specialized language and not a general-purpose programming language, and that most people shouldn't be using it.
Calling these goals "subjective" as if this justifies them is just a smarter-sounding way of saying "That's just, like, your opinion, man." Opinions can be wrong, and the opinions of the Go team are wrong.
I think Go has gotten fairly decent traction because there are roles for which real programmers find it reasonably well suited compared to existing alternatives, and I think that, not the previous work of the creators, is what drives attention to it.
OTOH, I think Go's period in the sun is going to be a lot shorter than, e.g., Rust's unless we see a Go 2.x that addresses some of the "not in the Go 1.x timeline" things with Go fairly soon.