I asked Rob Pike why they didn't add pattern-matching given that it already has multiple returns and some other baby steps in that direction. His response was, "We considered it, but it turned out to be too much work in the compiler."

That was a huge WTF to me. Isn't your job as a language designer to do that work so that I, the language user, don't have to?

The cost of complexity in the compiler is not only to the persons implementing it.

Also I'm pretty sure the amount of work in the compiler was only one of the considerations, and while I don't doubt your account of your conversation with rob, I doubt it was the main consideration in this design decision.

Channels + select are a pretty good replacement for what one usually uses pattern matching in Erlang.

There are pros and cons for both models, but they are roughly equivalent and I never missed pattern matching in Go.

Pattern matching isn't just a feature to aid concurrent programming; it's extremely helpful for all sorts of code. However, since Go doesn't have unions (either tagged or unsafe), pattern matching in Go wouldn't be particularly powerful anyway.