It's good that the author realizes that there is a tradeoff between the complexity of the language and the time and energy needed to bring new programmers up to speed on a project. This is something that gets missed really often.
However, I think the author completely misses the power of composition. It's usually the best alternative if you want to share code between different types in Go. I have written many large go programs without ever using the empty interface or typecasting (except of numeric types, where sometimes you need it because go doesn't ever do implicit conversions between numeric types.)
I agree that the behavior of storing nil in an interface is a wart.
The author spends a long time arguing against the idea that the use of sync and atomic should be discouraged. He claims that it is hypocritical because the standard library uses these packages. But it doesn't seem hypocritical to me to put tricky optimizations into the standard library, but discourage ordinary programmers from writing tricky code in their ordinary applications. The standard library has millions of users; most code has a handful. The tradeoffs are going to be different.
Besides, the author is arguing against a strawman here. Go has always given programmers access to low-level programming resources such as inline assembly, operating-system-specific calls, and even the ability to directly make non-portable Linux system calls. Compare this to Java, where up until very recently, you couldn't even create a symlink without using JNI because the authors were afraid it might be non-portable.
I think micro-benchmarking the performance of channels misses a lot of the point. OK so you have a microbenchmark where mutexes are 30% faster than channels in a tight loop-- and you're willing to give up all the benefits of channels for that? Talk about missing the point. And if your goroutine does anything interesting with what it's pulling out of the channel, this is even more irrelevant.