Erlang's design was driven by much stronger philosophical principles and an unusual initial use case (phone switch programming).
I'm not saying either is necessarily better and worse. The end result is that Go is a much more mainstream language with a lot of refinements, and Erlang is the sort of bizarre-but-oddly-useful language you get when a strong philosophy is carried through to its full logical conclusion. (See also Haskell.)
If you really, really care about compiler-enforced safety, Go is not a good choice. Not only will it let you shoot yourself in the foot, it won't really do that much to stop you. (Indeed, this presentation is almost terrifying from the perspective of an Erlang programmer, so many ways to screw up with the compiler only noticing a handful of them: [1] slides: [2]) However, if you're sort of interested in the sorts of things that can give you but aren't ready to put on the hair-shirt (a metaphor from the Haskell community), Go has some ways of putting your toes into the water and getting some of the practical benefits without a ton of the theory, for instance: http://www.jerf.org/iri/post/2923 . (Only some though.)
The downside of shared mutable state is that it pushes the burden of correctness out of the language and onto the programmer. With Erlang's approach, data races are impossible. With Go's approach, you have to apply an optional static analysis (the built-in data race detector) to give you any assurance of correctness (and that's only a heuristic, not a guarantee of correctness).
Modifying it by the sender after channel transmission is considered very bad form though the compiler allows it and you can safely get away with it as long as you properly mutex lock your accesses.