Every copy is a performance downside. There's plenty of applications where it is essential to use shared memory. You could not rewrite Linux to avoid shared memory between threads.
The line is fuzzy though.
You might say that each RAM access is really a message over a bus, and so is each cache access. Conversely, you could write a message passing style key value store and create race conditions by using like shared memory.
Transactional memory is also 'message passing' like -> you bundle up access of shared memory into a single transaction 'message'.
A lot of shared memory code uses constructions like FIFO/queues which are really not too distinct from message passing except when ownership is shared or goes back and forth. Perhaps that's just an 'implementation' of message passing.
Message-passing doesn't necessarily involve naïvely copying the data around. If you have access to shared memory then you can pass a pointer; the only thing you really need to ‘pass’ is the capability to access the message data. This is how seL4 does it, for example.
Of course if you don't have shared memory then you have to copy anyway :) And because of CPU caching architecture the benefits of having an owned copy of the data can sometimes outweigh the cost of copying it, even if shared memory is available.
Ok if you define message passing that broadly then I would agree, but I think that definition is also broad enough to bring in the downsides of shared memory such as deadlocking.
We're also now talking about patterns which are common in other contexts, but I don't have a problem with that. io_uring for example - is it shared memory, asynchronous, message passing, or all three (probably yes)?