There's nothing wrong with an opinionated desktop environment or even an opinionated Linux distribution. But, prior to GNOME 3, the project was highly configurable. Now it is not.
When people start up new highly opinionated projects (e.g. crunchbang, Omarchy), the feedback is generally more positive because those who try it and stick with it are the ones who like the project's opinions. The people who don't like those opinions just stop using it. There isn't a large, established base of longstanding users who are invested in workflows, features, and options.
Gnome 3 was a big update and adding options, which does happen, is not free. There were changes from Gnome 2 and 3 and adding some options "back" from Gnome 2 is really asking for that feature to be rewritten from scratch (not all the time, but a lot of the time).
That the Gnome team has different priorities from other DEs, one of them being "keep the design consistent and sustainable," is completely valid and preferred by many users like myself.
A new design metaphor can be "completely valid" and simultaneously an aggravating rug pull if it is pitched as a new numbered version of an existing program---especially an existing desktop environment that many people use daily---rather than as a new program.
> Gnome 3 was a big update and adding options, which does happen, is not free. There were changes from Gnome 2 and 3 and adding some options "back" from Gnome 2 is really asking for that feature to be rewritten from scratch (not all the time, but a lot of the time).
If the "next version" of a software project is really a near-total rewrite, such that many-to-most features from the previous version must be rewritten from scratch, then you should start a new project and pick a new name if you do not want your current users comparing the new version to the previous version. Whether or not those users appreciate the cost of feature rewrites to the developers' satisfaction, they already have working software with a long list of features and a version number one lower.
KDE had a similar problem moving from 3.5 to 4 (also a major rewrite), but the initial wave of complaints had more to do with instability and heavy resource use because they didn't abandon the desktop metaphor entirely. They also explicitly had a roadmap of building back in many of 3.5's features as time went on, which made it a less radical transition.
It's all ancient history at this point, at least on software timescales. But the Gnome 2 to Gnome 3 transition is up there with Python 2.7 to Python 3 as an example of how not to manage or implement a major change to a widely used piece of software.
The funniest thing to me is I used to think of Gnome 3 as a effort toward Apple-esque design which wasn't as well put together as MacOS... But now, even though Gnome today is still not up to the consistency of 2011 MacOS, it is more consistent than 2025 MacOS because Apple has been driving drunk on desktop software design for a decade and a half.
I guess I agree? I never used OS X and actively avoid MacOS post-2013 partly because of the layers of inconsistency each new version introduced (when I used a Macbook, there were about 4 different "overview of current running apps + method to launch new apps" interfaces, accessed from one hotkey, two separate mousepad gestures, and a button in the UI, respectively.)
To my tastes these days Gnome Shell and associated GTK3/4 apps (see Gnome Circle), plus Flathub, are easily the most consistent and pleasant desktop app experience around. YMMV of course. (I'm the type who has never felt the need to mess with Gnome Tweaks, extensions, etc., if that helps.)
I don't run it (yet), but Fedora Silverblue is the future (for consumers running desktop Linux). I believe this in my heart.
After dealing with this kind of stuff for 14 years, it shouldn't be surprising that you don't have a lot of folk left who are willing to extend good faith to Gnome devs.
Eventually, I found the bug report that was filed against the guideline itself. The person who wrote that part of the guideline had responded that he made the decision based on a poll (presumably of people in the mailing list), and that no-one really had a strong opinion on it. He asserted that it was no big deal, and refused to reconsider the guideline.
Now, I think it is perfectly OK to make the wrong decision when it comes to something outside your expertise. If you are a backend software expert, it is OK for you to do the wrong thing when it comes to the UI for a project you are supporting for free. But when someone who does know that field makes a reasoned suggestion, you should not really be doubling down.
A UI/UX designer in this situation is not exactly going to be prepared fork and maintain a whole stack over this. It just means that the experience will be worse for users.
