Not a valid excuse. The end users have their own productivity apps that eat up their system resources, too.

In the minds of developers, the end users shouldn't be running any other apps than the the app that the developer is working on.

Correct, it seems much better to create a test bed environment emulating this, rather than artificially constraining a person own development environment due to some poorly thought out policy which is actually likely a way to save money.

That's a complete non sequitur. The grandparent comment is not talking about how resource intensive background apps affect the performance of the product, it's talking about how the development tools themselves may not run smoothly and efficiently on shitty hardware if they are resource intensive.

Why had complex IDE's with drag'n'drop tools, syntax highlighting and intellisense that were happy to run on hardware not much better than a 486.

Developer tools are only resource hungry today because their developers aren't dogfooding.

They are resource intensive because they prioritize feature completeness over being sleek and lightweight. That's the correct thing to prioritize because, because extra RAM is dirt cheap compared to benefit of higher developer productivity.

That's the point, they already were feature complete back when they were less bloated. VS2017 offers very little over VS6.0 or VB6, I think they're min requirements were 128MB of RAM, it was a lot more responsive too. Similar for eclipse.

Developer productivity hasn't improved since, even gone backwards in some ways.