>Most users simply don't share your tolerance (preference?) for visually crowded interfaces that aim to cram as many elements on a screen as you can possibly fit with little editing or regard for what users actually 'need' on a screen for a given task.
I don't think anyone has a preference for needlessly crammed UIs. But the question is what you prioritise when a task really does benefit from seeing a lot of information at a glance.
There's an easy choice. There's a hard choice. And there's an ugly choice.
The easy choice is to "clean up" the interface and just remove stuff even if it makes the interface less useful. Apparently, that's a popular choice with designers. It can often be justified by pointing to "most users", because that creates a statistical bias toward less demanding requirements.
The hard (and expensive) choice is to think deeply about data visualisation, gain a detailed understanding of the task at hand to the point where the designer has to become a user themselves, and communicate with the most demanding users until you get something functional and not crammed or until you learn what customisation options are needed.
When the hard choice fails or isn't an option for economic reasons, that's when only ugly choices remain, and that's when I would rather have a developer who is intimately familiar with the task come up with a UI that is at least fit for purpose.
I'm not trying to be a jerk here, but this is an incredibly glib oversimplification of design. It's pretty pervasive too, especially in FOSS, which is why FOSS interfaces often suck so bad.
Not all coding is software design, and not arrangement of elements in an interface is interface design. If someone is taking an interface and making it "look nice" by removing beneficial components, then what they are doing is not design. Design is a process and a mentality, not a singular activity.
What you describe as the hard choice is merely a point (not even an extreme one) on the spectrum of what constitutes interface design. Broadly speaking, the first step, always, is to figure out what the user's goals are, to whatever extent possible. You might be able to do in-depth user research with focus groups and eye-tracking and put together user stories with A/B testing etc. etc. etc. You might only be able to do some personal research and play around with the software a bit and draw some diagrams. The second step is to figure out how you can help your users accomplish those goals most effectively through the arrangement and functionality of the on-screen elements. Without your primary concern being what the user actually needs, you're just decorating, or maybe organizing.
Reducing the amount of data on a screen isn't a end in itself. If it contributes to the user performing their task better, then great. If it inhibits it, it's the wrong choice. Any person with formal design training should be perfectly comfortable arranging a large amount of complex elements and information on a screen in a comprehensible way. See magazines, train timetables, newspapers, etc.
I don't think anyone has a preference for needlessly crammed UIs. But the question is what you prioritise when a task really does benefit from seeing a lot of information at a glance.
There's an easy choice. There's a hard choice. And there's an ugly choice.
The easy choice is to "clean up" the interface and just remove stuff even if it makes the interface less useful. Apparently, that's a popular choice with designers. It can often be justified by pointing to "most users", because that creates a statistical bias toward less demanding requirements.
The hard (and expensive) choice is to think deeply about data visualisation, gain a detailed understanding of the task at hand to the point where the designer has to become a user themselves, and communicate with the most demanding users until you get something functional and not crammed or until you learn what customisation options are needed.
When the hard choice fails or isn't an option for economic reasons, that's when only ugly choices remain, and that's when I would rather have a developer who is intimately familiar with the task come up with a UI that is at least fit for purpose.