Simplicity is deceivingly challenging, and quite different from simple-mindedness, which seems to be what the author is accusing Go of being.
Keeping code simple, elegant, and consistent is IMHO one of the most valuable principles a team can adhere to. Simple is not necessarily shorter, as short can often be subtle and sneaky rather than simple. Complex power tools can be fun to the inquiring mind, but the ultimate consumers of your product almost never appreciate how you built it, but almost always appreciate the final outcome.
A wise man once said: “Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?” - Brian Kernighan
How will you keep your code simple if your procedural bent causes you to create dependencies/coupling at will?
How will you keep your code simple if your variables are mutable?
Recipe for complexity and bug hell
Implicitly fulfilled interfaces make it trivial to decouple code, because I can pass a type to a function in a different package, and that package doesn't even need to know that type exists.
You're obviously pushing the pure functional route, which is nice, but 95% of code in production is procedural. There's a reason for that. I could speculate why, but I don't need to.