My point was that a programmer shouldn't need to share memory to write concurrent code. That statement is not wrong.
Yes it is. Unless you use Erlang or OS processes you are sharing memory. Or rather you not sharing it any more or less than all the other technologies you listed.
But I agree with your sentiment in general that shared memory and concurrency are not working well. That is why it is worthwhile learning Erlang if you want to be reliable, fault tolerant concurrent systems.
Also nothings stops your from using queues and threads so data is local to each thread and gets copied over the queue.
Actually, even actor-based systems share memory. If two actors A and B send a message to an actor C and expect a response from it, they are sharing memory: what's in C's state. Which can be different depending on whether C received A's message first or not.
Ok in that respect there is just one big pile of shared memory in the whole world, isn't it (maybe except for military air-gaped system). It is the equivalent of saying if A makes an HTTP post to server C the it shares memory. Well ok, I am not sure what you mean by "shared memory", usually it means living in the same heap. So can access it via a pointer or reference.
If we didn't have concurrency primitives, the only high level concurrency idioms we would have would be the ones that made it into the JVM, which is a very slow process.