POSIX and its derivatives build IPC into the OS as a core feature. In particular, POSIX is built around memory mappings and file descriptor inheritance, which means it is extraordinarily easy to make processes communicate.
I honestly have no idea what you mean by this statement.
Unix domain sockets are (1) fast, (2) primitive (just a file), (3) widely available, and (4) can be used between multiple processes extremely easily (use SOCK_DGRAM).
If it were easy than everyone would be doing it the same way and there wouldn't be a discussion about it.
With shared memory in particular, the issue gets tricky around signalling and locking aka indicating to other processes when new info is available, and when another process is accessing the data.
If anyone took just a moment to design an API that was user/developer centric, and worked back from there, it would look materially different from what is provided today.
Sockets aren't designed for IP networking. They date back to a time when it wasn't even clear TCP/IP would win vs. IPX/SPX. Or DECnet. AF_UNIX sockets have things that IP sockets can't even dream of doing (the very poorly named SCM_RIGHTS). And sockets don't really cover IP networking all that well, e.g. MPTCP and SCTP shenanigans to get multi-address & multi-stream connections.
That said, both sockets and mmap are low-level APIs. A higher level "user/developer centric" API indeed looks different.
POSIX has mutex and condition variable, is this not enough to do those things?
Moreover, it's a bit of a secondary thing.
The API would look something like a call function with a receive function/lambda on the receiving side, with memory possibly being 'handed over' or whatever. And so the level of abstraction would be slightly higher.
And it would be a no-brainer, well established thing. Searching for how to do that today and it's always complicated.