> All sorts of exploration and hilarity was lost.
About games, I agree with you. But when doing work, or even non-gaming fun things on a computer, "exploration and hilarity" are damn near the last things I want to be expected of me. I want to get things done in a cognitively efficient way, even if that's not the most temporally efficient way.
That means: if an application wants me to learn new skills, they should be limited enough as to be relevant to the immediate task, discoverable, and with a clear, immediate path towards competence.
No "Well, you want to do $x in a GUI, but have you considered learning the CLI? it's much more flexible, and the next 10 things you might want to do with $x will be so easy (once you've mastered the CLI)!" I may never need to do 10 more things with a given program/task; I may be happy to do what I need inefficiently but in a familiar way; if I do need to do more in the future, I'll set aside time to learn how rather than getting interrupted on my way to a specific goal unrelated to leveling up my proficiency at something.
The attitude of many people and ecosystems in the Linux community seems to be like that. The tools themselves are fine once you learn to use them, but the people and conventions that proliferate those tools seem to often lose sight of their (desktop, not power/dev/sysadmin) users' needs for immediate specific task-accessibility, discoverability, and incremental increases in proficiency rather than "exploratory" or deep-end-first learning styles.
I say this as someone who spends just as much time obsessively, wastefully over-customizing my development workflow/shell/etc. as most programmers I know. I do that for fun, but while I find it fun, I recognize that most of my users do not, and likely never will.
