> This is what usually happens if you let incompetent people make design decision: they stay with the first and worst version forever.
This is what usually happens when you confuse the decisions that mattered from the ones that didn't. It's like back before 'just use a linter' was the solution to code formatting. You'd start a project, you'd have the 'code style meeting' and everyone would bash themselves into the rocks of whitespace and bracket placement, and never get to things like code organization, structure, and naming of things.
So then you end up with code that uses the same noun in three places to mean 3 different things and uses it as a verb in a fourth.
You only get so many opportunities to really change the direction the boat is steering and you can wear out your welcome trying to exceed it. If you get some things right they'll let you do a few more.
Well, I had to be more specific instead of trying to be dramatic...
The thing is, nothing in the suggested procedure addresses the problem of how you are supposed to distinguish the decisions that matter from those that don't. Whoever came up with this idea must've thought that it's trivial to the point it doesn't need solving, but it's the opposite, unfortunately.
Also, FYO, linters aren't responsible for code formatting. It's the formatter's role. Linters advise on style. I.e. the problem of bracket placement is not solved by using linters, an example of problem that is solved by linters is the maximum number of properties a class is allowed to have.
But the meetings about formatting or using / disabling linter rules still happen. Having tools to do that didn't make the problem go away. What did happen, however, is something more like natural selection. The increased volume of newcomers which the field saw up until maybe five or so years ago were mostly steered in a particular "winning" direction. So, today, naturally, you have most people agree on a set of rules to follow because the majority came from the same background. You need a bunch of old-cadgers to work together on a project for there to be a feud over styling rules.