There is a cost, though. Low enough to bear in most cases, but transferring more state through IPC, the overhead of starting new processes, context switching between processes, duplication of in-memory structures; these can add up to make an equivalent Erlang program much more heavyweight on a system than a Go program using many goroutines.
Erlang processes are nothing at all like Unix processes. They are much, much smaller memory-wise as well as in terms of spawning/killing speed as they do not rely on system calls but rather the Erlang VM (which is highly tuned for these purposes).
Yes, there is a small overhead incurred when copying data between processes because the VM is truly copying the data[1], but the benefit gained is that you get per-process heap isolation (references can't cross process heap boundaries). This is important because in languages like Java or Go, one misbehaving bit of code that is causing a lot of GC to happen can "stop-the-world", and make your entire system pause (and it does happen[2]). This is not acceptable when writing soft real-time code, like say an auction system.
I'm not sure why you think an Erlang program is more heavyweight than Go. Is it due to Go programs being compiled to binary? Erlang can do that as well,[3] although it's not often done as Erlang requires a runtime, and it's often simpler to use a separate runtime. But you should know that Go also requires its own runtime to run Go programs[4], it's just that it is statically linked into your compiled code (which is what makes the resulting binaries so huge). But Erlang could do the same thing, it's just not really an industry practice.
Right tool for the job, yadda yadda. :)