I recently read an Ars Technica article on the history of Linux graphics, which contained the bald-faced line:

What made X so special, of course, is legendary. X was the first graphical interface to embrace a networked, distributed solution. [...]

Wrong. This is one of X's attributes, but it is not what made X special and successful. As I have touched on before, what made X so special is that it did not suck, it was portable, and oh yeah, it was free. That it was network transparent was a nice feature, but it was not the dominant way that X was used in many environments (especially because this network transparency required a lot of work and special magic to make work in practice; it only became 'transparent' to real people when ssh came along and handled all of that behind the scenes).

In the mid 1980s when it first came out, using X meant that you could have the same interface and run the same programs on your Vaxes, your Suns, and various other systems. More to the point, you and your graduate students could write your graphical programs once, not once for every different sort of Unix workstation that you might have. You could do this for free, and the result worked okay and performed decently.

(With a bit of work you could write the same program so that it worked on workstations with a wide variety of display capabilities, too, all the way from black and white through various sorts of colour displays.)

No vendor system could offer anything close to these advantages. All they could offer, sometimes, was more GUI widgets, and not infrequently they got very important core features subtly or blatantly wrong.

(You could make a strong case that X succeeded because its authors spent so much effort making a very good terminal emulator, but that's another entry.)

Sidebar: why remote X is not so transparent in practice

There are two troublesome parts of starting X programs remotely; they need to know the correct display to use, and they need permission to access the display. Because of how X chose to work, handling either of these requires some programming.

Telling programs which display to use is somewhat complicated because your local setting for $DISPLAY generally won't work for remote programs; in most X environments, it doesn't have the machine name in it. So you have to transform it before passing it to the remote machine. This transformation is not difficult, but something has to do it (either the user by hand, or a script that someone writes for them).

Giving programs permission is much more complicated. Generally you need to transfer a specific 'magic cookie' to the remote machine and then combine it with the right name for your display in the process of loading it into an authorization storage. In theory you can do this by hand; in practice, no, it has to be automated with a script and for added annoyance the script needs to run commands remotely on the target machine.

You could create a script environment that enabled you to do things like 'not-ssh yonge.cs xterm' (as I've discussed, I did), but it was not a simple script. And it didn't work in as many environments as ssh works today.