I've come to essentially the same conclusion.

Go is performant, parallel, has good error idioms, good library support for protocols, and is generally great for writing services.

It's also terrible at metaprogramming, has poor native GUI support, is maintained by a corporation which could abandon it or go bankrupt, and generally ignores thirty years of language theory. (Seriously, it's 2015, why do we still have statements?)

They’re not capable of understanding a brilliant language

Exactly. I push Go at work because it's great for services, and it's an Algol-derivative, which means a much bigger talent pool than better languages like Erlang, Clojure, Haskell. It's not the best language in a vacuum, but it's one of the best in the environment we're in.

Some points I disagree with:

remarkably difficult to maintain and slow. I think this is characteristic of statically and dynamically typed languages in general. Dynamic typing allows you to quickly build and iterate but lacks the static-analysis tooling needed for larger codebases and performance characteristics required for more real-time systems.

Erlang and Common Lisp beg to differ.

Go’s type system is impaired

The lack of generics is a metaprogramming failure, not a type system failure.

[interfaces] also can cause some subtle problems like accidental implementation.

In theory. I've yet to encounter it in practice.

Go is not a replacement for C/C++ but a replacement for Java, Python, and the like

It's both. Go's performance is on par with C++. It's not a replacement for C, unless you're using C for things you shouldn't. But it absolutely competes with C++ and other systems-level languages (e.g. Rust, D, Nim).

Incidentally, if you want a 'C++ level' language with real metaprogramming, check out Nim. It hasn't seen the industry adoption that Go has, but it's a performant Algol-derivative with real Common Lisp–style macros.