I've quickly realized that (apart from being free!) that a lot of long-term Linux/Unix users LOVE the hands-on 'Under-The-Hood' abilities, and
actually can/do swear by the speed & technical accomplishments they can achieve without even a 'GUI' as such! (And I can grasp that!)
And I further understand now, the myriad of GUI Distros & their included software/apps, that is very much a personal choice in most scenarios...
If you logically examine this further, you'll see it is all about
workflow. And that is what I believe matters: having the tool conform to ones workflow, instead of having the tool dictate which workflows are "allowed" or possible.
Then, considering a tool separately from any workflow(s), becomes utterly goofy: like five-year-old kids talking about what make and model car they'll buy when they're old enough. (Such talk is fun, though; it just doesn't have much to do with real life.)
That's what programmers/coders are for... do do the hard work behind the scenes, to simplify things for the 'majority' of normal users. However,
it 'seems' that a LOT of Linux-Style 'users', seem to be generally 'technical' in their nature, and LIKE to delve deep & play !
Yes, because those are the users/developers that contribute to Linux. It would be silly to expect such user-devs to try to make the tool they use less intuitive/effective/efficient for themselves, just so that it would be more
popular, especially since statistically, such personality types tend to be more focused on things rather than people.
(Those paying for Linux development use Linux either in embedded devices and appliances (where the end users don't know they're using a "computer", much less Linux, at all), or highly technical environments – software development, HPC, servers, etc.; and AIUI the humans involved are much more technically-oriented than average computer users, so it makes sense that even those paying for Linux development, generally target more technical users too.)
Obviously, there are lots of things in Linux (the kernel, the GNU parts, and the distributions) that need fixing, and a lot of development that does not actually make sense to many of us... but because of the licensing, it is not a matter of what is possible or allowed, only a matter of what is
feasible, time/effort/cost-wise. The correct question to any workflow-related issue is not "Could we ... ?", but "How ... efficiently/effectively?" – and this distinction is something a lot of people do not grok; that the answer is a spectrum of options depending on the context and personal preferences, even less. Freedom is fun only when it's also simple, I guess.
I do believe you are beginning to see both the options and their relative "costs" when it comes to things Linux-y, sir.