I think you're missing the point of the basic type system: simplicity. It's a bigger win than you think when it comes to attracting new developers and making code easier to read. Sure, there are languages that let you write more succinct code and support all sorts of crazy typing, but one of the things good code requires is readability.
Your code my be terse and elegant, but if other people can't understand it, it won't matter. Code is as much communication to other developers as it is to the computer it runs on. That's why I credit simplicity as Go's greatest strength.
Of course a complex language can be used to write simple code and vice versa. Ultimately every program is going to increase in complexity-- that quote about failure vs legacy nightmare applies here.
IMHO it's better to reduce the complexity of the language to a minimum so that language/runtime complexity doesn't have a multiplicative effect on application code complexity.
For instance, C++ is a complex language. That complexity inevitably accrues to applications written in C++. This is a conscious trade-off of the language -- performance + high level programming, or what have you.
In the end, though, I am not sure I'd argue there's much correlation between simplicity of the language and simplicity of the code. It's too hard to get anyone to agree on what simple means anyway. Me, I prefer Hickey's "Simple Made Easy" for that, but not everyone agrees.
ETA: I guess what I would say is: would you prefer to start with something simpler and build complexity appropriate to the problem domain out of simple, but sound ideas? Or would you prefer to start with a set of inherently complex primitives and build something else complex on top of that? It's subjective, but I've probably leaked my bias in the phrasing.
I don't think his point is as broad as you're claiming. He's saying that golang application code is complex due to (for example) lack of generics because the language lacks that complexity.
I am very wary of arguments about simplicity, as what people usually mean by "simplicity" is "stuff I already know". Indeed I believe this is a large part of the reason for the popularity of Go: it is basically a statically typed and performant Python / Ruby. You don't need to learn much new to use it if you already know these languages.
The problem with this is how are we to advance if we never adopt new ideas?
Furthermore, I believe that the core of functional languages are very simple. Do you understand logical ands and ors? Then you understand algebraic data types. Do you understand high school algebra? Then you understand generics and higher kinds. It's all very simple but just maybe not stuff you're used to.
This is a false dichotomy. There's a pretty wide continuum between type systems at least expressive enough to represent a user-defined list of a generic type and "all sorts of crazy typing".
I think you're missing the point of the basic type system: simplicity. It's a bigger win than you think when it comes to attracting new developers
...and that brings us full-circle to the blog post: rounding the corners so that the developers don't cut themselves and avoiding ideas that require developers to get out of their comfort-zones is exactly what made Java so successful. It put OO within the reach of mortals who were unwilling or unable to absorb C++. Go, being simple and unadventurous could very well skyrocket into the Java/COBOL stratosphere.
Your code my be terse and elegant, but if other people can't understand it, it won't matter. Code is as much communication to other developers as it is to the computer it runs on. That's why I credit simplicity as Go's greatest strength.