Yes, I know. And from an abstraction level, it's really cool that it works that way. But when you are operating on the same node, asynchronous message passing is sometimes an awkward and less performant solution. It's strictly weaker than synchronous message passing, which means you never have any assurance that the other process received your message. Message passing can also be less performant than properly protected usage of shared memory, which transactional memory allows.
Erlang's popularity for concurrent programming probably comes down to the fact that anything is better than manually managed locks and until recently there weren't any widely-used industrial languages that used synchronous message passing or transactional memory. I don't think it's any coincidence, though, that the designers of more recent concurrent languages like Go and Clojure have not followed the Erlang model.
On the motherboard # of cores will be increases but at some point, while we get the hang of concurrency and restructure our codebase, we'll quickly get hungry for more cores and memory than a single server can support.
What happens then Erlang program won't have to be restructured when that happens because it provides a suitable abstraction. At the lowest level it will still be Pid ! Msg. That is the beauty of it.