One can always start up multiple Python processes, though.

You can, but communication between processes is usually more difficult than communication between threads. Sometimes you want to do more than pass messages. For example, you might want to do something as simple as increment a single counter. Sharing a counter efficiently among processes is not so easy.

It is true that communication between processes is more difficult, but solving ipc also allows distributing actors across the network for free, so there is a lot of advantage to be gained by allowing for out of process actors.

I don't understand your counter example at all. Are you saying that sometimes you share memory (the counter) between Actors in the same process? Because that is not Actors, and you should probably find something else to call it instead.

If your only communication mechanism is actors, then you're right: several process would be fine. But I think that almost any software built with actors requires some shared memory as well. Even Erlang has ETS. In the demo, we use an in-memory spatial database. It's this shared data store that's hard to get right with several processors, especially if it is supposed to help with parallelization and scheduling.

BTW, Quasar also has distributed actors.