You'd have optimisation that happened at the 'connect' phase, which analyzed both binaries, and metadata left by the compiler in each, and optimized the machine code by stripping out unused fields and all the code to generate them.
It could also 'inline' some IPC calls by moving server code to the client.
How do expect to ever manage to do that if server and client aren't even guaranteed to be the same language?
COM is one of the most battle tested IPC in production, with support for in-process shared libraries, and Microsoft never was crazy enough to try such optimizations on the Windows dynamic linker when loading COM libraries.
That's a really cool concept I hadn't considered. But ... Too futuristic maybe? I think this operates somewhat closer to a syscall/ABI than a calling convention/FFI than you'd expect.
It could also 'inline' some IPC calls by moving server code to the client.