Go's concurrency isn't even that good. It just looks good for anyone coming from the languages which don't have that (which are the majority).
One of the earliest high level languages with powerful concurrency and parallelism APIs are C# and F# (TPL and Parallel/PLINQ, some of which was available back in 2010).
They are certainly different, but to say there is nothing similar is plainly untrue - apart from nominal vs structural, they are pretty much the same.
I'm not sure how significant the nominal vs structural distinction even is. In Go, a struct can implement an interface without declaring it, but the programmer still needs to deliberately write the struct to conform to the definition of the interface, so they're still coupled, just not explicitly [1]. Yes, it is possible to define a new interface which fits existing structs which weren't designed for it - but how common is that? That is, how common is it for two or more structs to have a meaningful overlapping set of methods without being designed to conform to some pre-existing interface?
Go's nominal interface feature is definitely interesting, but that section doesn't talk about how amazing it was to implement interfaces implicitly:
> That notion quickly grew into the idea that value types had behaviors, defined as methods, and that sets of methods could provide interfaces that functions could operate on. Go's interfaces arose pretty much right away.
If you replace Go with Java, this would've accurately described Java ~30 years ago.
As the review Chen links discusses, it turns out that M:N threading (i.e. goroutines) and good C compatibility are mutually exclusive. Go went one way, every other language went the other way. The most common alternative is stackless coroutines, which are much more widely implemented than the Go model.
To the extent that Go has features that no other popular language has, it is not influential. To the extent to which it invented those things, it's not influential. And that's why he didn't make that claim, he made a much broader one. The only problem is, if you make the broader one, it's obvious it's F#/C# that's been influential.
Erlang's processes might have similar semantics to Go's goroutines (green threads) but Erlang is a much simpler language, because it doesn't have shared state.
A lot of work went into optimizing Go's GC to be able to cope with concurrency.
Actually, name just one that has either, even today!