Yes, my point is that Go intentionally makes it hard for users to extend the language, while simultaneously learning from the successes and failures of other languages, and Yes, my point is that Go intentionally makes it hard for users to extend the language, while simultaneously learning from the successes and failures of other languages, and incorporating the results of that into Go.
The fact that users are able to create core language features has its drawbacks when it comes to cohesion in the language community. Lisp itself is a perfect example of this - codebases are immensely fragmented in terms of which libraries they end up using (Quicklisp is, in part, an effort to solve this).
Lisp was "designed" (if you can call it that) around the principle that extending a language should be as easy as writing a program in that language. Go was designed around the principle that there should be only one dialect of the programming language, for the sake of cohesiveness.
Both are legitimate philosophies for different use cases, but that's why it's kind of silly (IMHO) to compare Go to Lisp - the goals are not only different, but diametrically opposed in most ways.
I think the problem with Lisp is that it grew organically from a large community across multiple languages and 50 years of life. Not that the language was excessively expressive.
Go, on the other hand, was designed and implemented from a single vendor in a handful of years. That makes it far easier to provide a single, coherent platform. Once you provide a coherent, complete platform you don't need your users to solve every edge-case by implementing their own language features.
Any language that doesn't provide some kind of code-that-writes-code workflow will eventually leave its developers dealing with frustrating boilerplate.
You've completely missed the article's point: users were able to create CLOS before it got integrated in the language.