You'd think, wouldn't you? But in some regards they still feel less responsive than the desktop of a sub-10MHz machine from the 1980s.

(I'm not kidding - the tight coupling of quadrature-based mouse counters and hardware sprite mouse cursor - bypassing all the wireless, serial / PS/2 / USB encoding and decoding we have today - and on-screen gadgets being drawn and redrawn in the input subsystem's context without messages having to trickle through a ten foot long pipeline of frameworks and UI toolkits, all gave a sense of immediacy, of "having the computer's full attention", that's rare to find in today's world of janky semi-functional web apps.)

Not necessarily the environment, but compositor itself must be fast. It shouldn't introduce any delays that would affect for instance input latency in its processing loop. Gamers would for sure complain.

Someone could totally make it do everything in a single thread and not think about that, which would be pretty bad.

They should be, but with the speed and resources available on machines these days, people don't spend as much time optimising every little thing, and even make trade-offs, e.g. Gnome 3 desktop has the spidermonkey javascript engine in it, and an increasing numbers of components are using javascript.

Depends on how much Electron crap is running alongside the desktop.

“Don’t you guys have fast computers?”

We are called power users ;-) we can do more than one thing or ten things at a time and want things to be responsive and fast and not drop frames and not crash the whole session when some plugin fails etc etc. you know, a well designed thing