NeWS wasn't the only windowing system to use Display PostScript. The other big one was NeXTSTEP which obviously became OS X.
The most important ability that NeWS had, but was missing from Display PostScript and its successors (OS/X Core Graphics, PDF, SVG, canvas API, etc), is the ability to download code to create an efficient custom high level application specific protocol between the client and server.
That essential ability is what people call "AJAX" these days, now that PostScript has been supplanted by JavaScript and a whole bunch of different APIs, and now we're even downloading shaders to the GPU! Truly exciting!
James Gosling chose PostScript from the start, for how its network programming ability dovetails with its graphics and data representation, instead of nailing it onto the side of a bunch of different technologies as an afterthought.
To quote the comparison from the wikipedia article:
NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently:
1) used PostScript code instead of JavaScript for programming.
2) used PostScript graphics instead of DHTML and CSS for rendering.
3) used PostScript data instead of XML and JSON for data representation.
From: James Gosling <jag@Sun.COM>
Subject: Re: Display PS vs NeWS
Date: 22 December 1988 at 19:35:08 GMT+1
To: Robin Schaufler <robin@Sun.COM>
Cc: don@brillig.umd.edu (Don Hopkins), sevans%norquay@Sun.COM
James: The thing that we don't have is a thousand caveats on what can be assigned to what. You can't have pointers that cross spaces in Adobe's scheme, so as you read through their documentation you find zillions of restrictions that make life very difficult. Also, the "kill the process group..." doesn't really apply: they don't have process groups. Each process is alone. If you want to share, you have to stick stuff in the "shared" space or be forked from a common parent. save/restore has bizarre semantics in this memory model: eg. if a process executes "save" then any other process that shares the same storage pool is blocked (honest, I'm not making this up!)
Robin: We also can't emulate their lock mechanism. I had the distinct impression that they analysed NeWS monitors completely, figured out exactly what was wrong with them, and fixed it. I really like this extension, but again, considerable work for us (tho less than for the memory management extension).
James: Far from considerable work and of dubious value: almost no one has ever used locks. DPS locks are identical to NeWS monitors (they're even applied with the same primitive "monitor"). NeWS is missing condition variables, which are a good idea but not difficult to implement. Events are the common form of process syncronization in NeWS.
Robin: Another area we would have trouble emulating is their new halftoning operators, but that seems like less of a problem. The new operators allow for tiling, which we've implemented for X, but we'd still have to hook it up for NeWS, and provide their model, which isn't quite the same model. Actually, NeWS probably can emulate it but it would be beastly slow.
James: Actually, the DPS threshhold are NOT the tiling operators that PostScript so badly needs. If you read it carefully, for devices with more than one bit per pixel you can't get the tiling effect. Halftones continue to only be useful for halftoning.
Robin: In a few cases they picked the same names and operator spec as us, but in general they didn't try to be compatible. A few incompatibilities seem gratuitious to me.
James: eg. processes