But most implementation implements message sends/receives under the hood as method/function calls because it's far more efficient. The conceptual difference is small, and easy to support as method/function calls. The cost in overhead of putting them even in a different thread, much less on a different core or different CPU would be a huge problem for processes that aren't inherently possible to parallelise efficiently.
Performance isn't the only reason to dislike Smalltalk-style message passing. A far more important one is the ability to actually reason about your programs (i.e., make inferences about what they will do when run, without actually having to run them), besides just testing objects as black boxes. Traditional imperative programmers can use Hoare triples and predicate transformers. Functional programmers can use any of the various semantic models that have been constructed for all sorts of lambda calculi. What on Earth does the poor object-oriented programmer who wants to understand his program have?
Most interesting invariants span multiple data structures. For example, when you parallelize matrix multiplication, your invariant is product of the sequence of matrices, and what varies throughout the process is the length of the sequence. Presumably, for your sanity's sake, you want to consider each matrix a separate data structure.
In case you didn't understand the point to my first reply: Object invariants aren't powerful enough to describe how objects relate to one another, precisely because objects don't tell anything about their internal data structure to the rest of the world.
Fwiu swift is planning to implement actor style concurrency in a year or two. Which, if done properly, would be much much more interesting than what objective-c dynamic dispatch offers (see OTP for an example of what a full blown actor model offers).
And then we arrive at the conclusion that, on a machine where any active object that's executing something can be partitioned to a single CPU core, implementations do not need to compromise anymore.
The vat model addresses this directly by encouraging partitioning of algorithms into "plans", which interleave in execution while still being easily separable onto different threads.
