I don't have an immediate factual retort, but I personally have never experienced any performance issues. Do you have some form of benchmark or evidence you'd want to see on Plan9's performance?
We have tried queued 9p responses, multiple 9p packets in the same tcp packet, extensions to the protocol. Nothing seems satisfactory enough to make it into the core.
Given the need to retrofit X11 with various mechanisms for fast local access to framebuffer or graphics accelerator, I have never been convinced that the 8 1/2 and Rio window systems, in which all drawing happened through streams of bytes, were complete and future-ready graphics systems.
I wonder if the "everything is a file" principle is actually Plan 9's weakness, a simplistic oversimplification of the nature of OS resources. What if we keep Plan 9's structure/topology (private namespaces, network transparency where possible) but redesign the fundamental file abstraction. Maybe this needs to happen at the level of a new instruction set which provides primitive data block transfer operations which can be implemented efficiently e.g. by memory mapping or dma on local hardware and which automatically fallback to streaming in the network case. Not new silicon but a fast virtual machine which provides network transparency and high performance where possible.
We can play Quake though so it's not all bad :)
As for drawing. Plan9 is intended to be used graphically. Although the interface is by majority text (which is very handy). Images and window usage in general is as run of the mill as would be expected in a graphical environment.
Also communication with the X server can use shared memory - AIUI the modern GUI toolkits render everything to buffers themselves rather than using X drawing protocol calls, so I suspect drawing on modern linux is mostly a shared-memory thing.
I'm just saying unixes have done it a similar way to Plan 9 since almost forever - and it's not that big of a deal.