I'm afraid but you're wrong
"The *real* error in this statement is that it increased the attack surface. The graphics system had previously been running in the Win32 client-server service. This *is* user-mode code, but was running as SYSTEM and the session manager would shut-down the entire system if anything went wrong with that process"
No, the statement remains true. And your assertion is also true. Running as SYSTEM means that the graphics code had root level privileges and thus the attack surface was equivalent. However, it is possible to evolve that to something more isolated in the future if you keep the graphics code running in its own user space. The key point here is that the day they decided to move the graphics code to the kernel, they closed any possible enhancements towards a more clean and segregated architecture. So it still stands true that it was a bad design decision.
We have to be also considerate with the people that made that decision. At the time, the internet had just been invented and no one anticipated a world of exposed systems like the one we have today. It made sense at the time, and likely gave them a performance edge over the competition, as well as opening Windows NT class OSs to high end gaming and other areas where graphics performance was key. So at the time it was not a bad decision.
"So ... if you could provoke a crash in the NT3.x graphics system, it would take the entire system with it"
Mmmmm... that was not my experience. You could crash the graphics system and the rest of services were still running. That is, if you crashed the GUI of a file server, the box would continue serving files just fine.
True, for a system that had no concept of "command line only" usage, the only fix to get the GUI back is a reboot, but that does not mean that crashing the GUI crashed the whole system. As stated above, the system could have evolved to a cleaner separation of duties between GUI and kernel, like Unix has. But that cannot happen if the graphics code is in the kernel.