> приложение может рисоваться на стороне графического сервера, благодаря чему не гонять растр почём зря туда-сюда по соединению с ним или через костыли его обхода

Сегодня именно Xorg выглядит ненужным костылём, лишней прослойкой между приложением и видеокартой. Растры загружаются в видеопамять в виде текстур, и рисуются оттуда. Загружать же эти текстуры сначала в процесс X'ов, чтобы тот потом загружал бы их в видеопамять -- зачем, если это можно сделать непосредственно из прикладного процесса?

Собственно эта мысль -- загружать объёмные данные в видеокарту единожды -- возникла очень давно. Это творили вовсю ещё в 80-е DOS'е на EGA видеокартах (возможно ещё и раньше, но я так далеко не заглядывал). X был необходимым решением для систем, которые ограничивают доступ к железу прикладным процессам -- по разным причинам было невозможно просто позволить приложениям выделять себе куски видеопамяти, мапить их в адресное пространство процесса и работать с ними. Но решение в стиле Xorg'а уже не нужно, в виду существования DRM: https://en.wikipedia.org/wiki/Direct_Rendering_Manager.
Xorg продолжает быть востребованным, потому что DRM не решает всех проблем конкурентного сосуществования многих окошек на экране, но проблема многократной загрузки растров в видеокарту решается DRM'ом в ноль: процесс получает кусок видеопамяти и хранит свои растры там, отправляя видеокарте лишь последовательность команд, которая эти растры как-нибудь там выводит, накладывая друг на друга, применяя какие-нибудь фильтры, определяемые фрагментными шейдерами (да-да, если рассматривать видеокарту как аналог сервера Xorg, то это выполнение своих подпрограмм в "серверном" контексте), или даже отрисовывая векторный шрифт, хотя это, я думаю, не лучший способ рисовать много текста на экран, лучше, наверное, отрисовать глифы единожды под выбранный dpi в текстуру, и потом выводить их, текстурируя bounding box'ы символов на экране.