The features would break if they were built in.

You can’t know that and I can’t imagine it would be true. If the plugins many folks find essential were incorporated into GNOME itself then they’d be updated where necessary as a matter of course in developing a new release.

GNOME has clear philosophy and they work for themselves, not for you so they decide what features they care to invest time and what features they don’t care about.

You’re not wrong! This is an arrogant and common take produced in poor taste though. A holdover from the elitism that continues to plague so many projects. Design philosophy leads UX decision making and the proper first goal for any good and functional design is user accessibility. This is not limited to accomodations we deem worthy of our attention.

Good artists set ego aside to better serve their art. Engineers must set pet peeves aside to better serve their projects. If what they find irksome gets in the way of their ability to build functionally better bridges, homes, and software then it isn’t reality which has failed to live up to the Engineer’s standards. This is where GNOME, and many other projects, fall short. Defenders standing stalwart on the technical correctness of a volunteer’s lack of obligation to those whose needs they ostensibly labor for does not induce rightness. It exposes the masturbatory nature of the facade.

Engineers have every right to bake in options catering to their pet peeves (even making them the defaults). That’s not the issue. When those opinions disallow addressing the accessibility needs of those who like and use what they’ve built there is no justification other than naked pride. This is foolish.

Having a standardised method for plugins is in my opinion good enough, nobody forces you to use extensions. And if you don’t want extensions to break, then wait till the extensions are ready prior updating GNOME.

I agree! Having a standardized method for plugins is good, however; the argument which follows misses the point. GNOME lucked into a good pole position as one of the default GNU/Linux DEs and has enjoyed the benefit of that exposure. Continuing to ignore obvious failures in method elsewhere while enshrining chosen paradigms of tool use as sacrosanct alienates users for whom those paradigms are neither resonant nor useful.

No one will force Engineers to use accessibility features they don’t need. Not needing them doesn’t justify refusing the build them. Not building them as able is an abdication of social responsibility. If an engineer does not believe they have any social responsibility then they shouldn’t participate in projects whose published design philosophy includes language such as:

People are at the heart of GNOME design. Wherever possible, we seek to be as inclusive as possible. This means accommodating different physical abilities, cultures, and device form factors. Our software requires little specialist knowledge and technical ability.

Their walk isn’t matching their talk in a few areas and it is right and good to call them to task for it.

Post statement: This is coming from someone who drives Linux daily, mostly from the console, and prefers GNOME to KDE. All of the above is meant without vitriol or ire and sent in the spirit of progress and solidarity.

How? What mechanisms, conditions, etc, are we manipulating which produce such a significant effect? After a bit of searching I found this write up:

https://thor3d.ca/wp/the-effects-of-print-orientation-on-strength/

Is this what we’re referring to? To summarize (if I’ve understood this properly): Printing at 45 degrees ensures none of the print’s three axes are aligned with the printer’s least accurate axis of movement.