Put it another way: traditionally, the X server and X clients live in distinct address spaces for security reasons. You don't want a rogue X client trashing other clients or even taking the X server down. The price for this safety is high. You have to make Xlib calls, which have to create protocol, which has to be pushed into pipes or sockets. Data has to be reformatted and copied from here to there. On the server side, you have to scan the header, decode the major an minor protocol numbers. Dispatch from a giant switch statement: case draw-line: case blit: Hundreds of thousands of CPU cycles just to perform some silly graphics operation safely. If you're into SQL, you get the same raw deal, hundreds of thousands of CPU cycles to query some puny 100 byte record. Imagine instead being able to get the same function, with the same amount of safety, but this time with only the overhead of a subroutine call. Can you say 'screaming performance'?
Traditionally, in Unix, there is only one privileged process on the hardware, and its called the kernel. User programs get to SVC into the kernel, and thus kernel calls are reasonably fast. Yeah, sure, there's FLIH and SLIH (top half and bottom half) type overheads, and etc. but imagine how bad life could have been if every kernel access had the same overhead as between X client and X server, or SQL client and SQL server? Now imagine a world where the kernel isn't the only privileged process, where there can be many of them, where every server could be one. Where it could be done with the same safety and rigor and separation as between kernel and user. And with the performance of a system call.
Its not a world we Unix hackers live in now, and its not a world that most people have thought about or are even aware of. Its not a thing you can do with ordinary CPU's. But look at computing history: once upon a time, many CPU's didn't have virtual memory. Now they all do. Well, the hardware for multiple address spaces isn't really any more complicated than the hardware for virtual memory. Meanwhile, its available now on the mainframe, and if we ever get Linux/390 working, it will be a computing playground.
The Intel world is slowly discovering VMware. Well, you can say that VM is like that. Except that its done right. Because, unlike the Intel chips, the mainframe CPU's has the stuff that you need built-in. Not kludged around.
The VM crowd seems to like Linux/390. Why? I can't speak for others, but I think that Linux can give VM new life by endowing it with a modern command line and modern utilities. And give 'em an excuse to hack on VM some more.