I get what you mean. A lot of developers that do not care about quality will use practicality and pragmatism to justify committing “substandard” code.
Unfortunately there is no easy answer to when you should throw away “best practice”. From a distance it can be hard to distinguish between when someone is breaking the rules they know well for justified reasons versus when someone is ignorant and dismissive of all rules and conventions.
A way I try to reframe these arguments is to change the scale. For example, if we had two choices, what would they look like if we had 10x, 100x the features, files/classes/functions, to maintain?
A more concrete example is if we allowed deep nesting of packages, how deep is too deep? Most people would agree that 100 levels is not dev friendly.
For another example, I find that those who just read Clean Code will often break up their 100 line method into 10 line private methods that are often chained together. How does this scale when you have 1000 lines of transactional code? I often argue that when you chain private methods that only have one caller it’s better to inline it as at least all the code is in one place. If you really want to refactor properly, write 10 purely functional methods — this is my opinion and others may not feel this way.
I would say that when chopping and changing convention you are straying from being pragmatic. If you are changing convention all the time, you may have chosen the wrong framework to work with. By having your own mutated process it increases training time, so if you can catch this earlier it may be better find find a solution that’s more aligned to the teams goals that doesn’t require so many customisations.
