How times change
I'm putting my old-foagy hat on here, because there is a lot of history behind X.
When X was first deployed in the mid 1980s and early 1990s, it used to be that you did not have a graphical login. The sequence was nearly always that you logged in using a text-based login mechanism, and then you started X up with startx or xinit command.
What this meant was that the X-server was run as you as a user, rather than as root, a privileged user. Indeed, as I write this, I've just switched across to an AIX 7.1 system that does run an X server (it's the enterprise management system for an AIX cluster), and I can see that the /usr/bin/X11/X binary does not even have the set-uid-on-execution bit set, so on a traditional UNIX system using code derived from the MIT X11 code, the X server certainly does not need to be run as root when started using the old methods (I've just tested this as well, and startx still works, and still starts up MWM on an AIX system. How quaint!)
Whilst this does not alter the fact that an oversight in the code could cause the problem documented here, it would mean that any exposure will not have root access.
At some point, some bright-spark decided that a graphical login process was a good idea, so they started X (as root) before the user logged in. I would need to check, but I'm fairly certain that the original xdm (X Display Manager) actually re-spawned the X server as the user when you logged in on the console of a system, but it is certain that the CDE dtlogin, and GDM and whatever KDE uses for graphical logins keeps the server running as root, with the correct X cookies in the xauth file to allow the user's X clients to connect.
This is a broken concept. It was originally intended that the X server process should be running as a non-privileged user. It would have been pretty simple to start the X server as a non-root placeholder user, rather than root, but I guess that nobody thought of it as a problem.
I'm not sure whether there are any of the X extensions (like DRM) which need to be able to talk directly to the hardware as a privileged user, but the original intention was that the X server would not be privileged.
But anyway, who uses BDF fonts any more. They're pretty obsolete, and to exploit this, you would have to put a compromised font in the correct place, and then re-start the X server. As the default locations for the fonts are in a directory that an ordinary user does not have access to, as is the initial starting configuration for the X server, it would require root access to put the fonts file in the directories in the first place, which rather negates the value of the exploit! If I already had root access on a system, there are a whole load more back-doors that I could add without going through this rigmarole.
I suppose it may be possible to place the font file in the users own file space, then trigger a font path change and/or font rehash with the server running. It would be interesting to see whether this would actually crash the X server. I might give it a try.