Theres no doubt about them being a great concurrency model, which is why Erlang uses this approach. Shared-nothing message passing is actually my favorite non-dataflow approach to tackling not only concurrency, but also a means to build flat hierarchical software components.
However, there are some problems which are not easily modeled in this way. Some people claim that for some problems, this method isn't suitable at all (I'm more inclined to say that its simply more difficult or messy, but IMHO thats reason enough). Sometimes shared memory based concurrency is needed for performance. Whatever the reason, I'm not convinced that channels are enough.
This is one reason why I like Clojure's concurrency support: clojure's agents are similar to go's channels, but clojure also supports shared state, using software transactional memory to ease the locking/synchronization pain. Also, since clojure code is, by default, functional, operating on immutable data-structures, a lot of logic is inherently thread-safe at no effort to the programmer. Yet in some cases even that isn't desirable. So it lets you code however you need, and since Clojure is hosted on the JVM, you can revert to using Javas monitor-based concurrency model when it makes sense.
I don't think Clojure solves the worlds concurrency issues, but I'd argue its a lot closer to doing so than Go, even if its just because it gives you the choice to pick the model that suits your particular problem the best.
I don't actually mean to be advertising Clojure, its simply the most concurrency-oriented language I've been spending a lot of time using lately, so its easier for me to compare and contrast Go with it.