I don't think I've ever seen this combination of "very much cares about code quality" and "slow coder".
I humbly submit that you have been exceptionally lucky in that case, unless you're quite new to the industry. We've had problems with dogmatic developers and architecture astronauts for as long as software development has been a thing.
In the 1990s, they were the ones trying to shoehorn as many design patterns as possible into every OO project. There was little evidence that doing so made the code better in any material way, but that didn't matter, because Design Patterns Are Good Things.
In the 2000s, they were the ones adding lots of artificial complexity to otherwise reasonable designs to enable their preferred test automation tool to hook in everywhere. There was little evidence that enforcing these rules universally actually improved quality or saved time, but Everything Must Be Unit Tested.
In the 2010s, they were the ones refactoring anything with more than five lines in a function or more than one level of nesting. There was little evidence that this improved any important code metrics, and even some evidence that it actually made things worse, but the longer or deeper version violated someone's arbitrary list of Code Smells That Are Bad so it had to be fixed.
A recurring theme here is taking the essence of a reasonable idea that might be useful in some circumstances but then applying it with an absurd degree of rigidity and scope without regard for the cost-benefit trade-offs being made. XP advocates even made this the centrepiece of their philosophy, though XP was born out of a project that was hardly a great success...
I humbly submit that you have been exceptionally lucky in that case, unless you're quite new to the industry. We've had problems with dogmatic developers and architecture astronauts for as long as software development has been a thing.
In the 1990s, they were the ones trying to shoehorn as many design patterns as possible into every OO project. There was little evidence that doing so made the code better in any material way, but that didn't matter, because Design Patterns Are Good Things.
In the 2000s, they were the ones adding lots of artificial complexity to otherwise reasonable designs to enable their preferred test automation tool to hook in everywhere. There was little evidence that enforcing these rules universally actually improved quality or saved time, but Everything Must Be Unit Tested.
In the 2010s, they were the ones refactoring anything with more than five lines in a function or more than one level of nesting. There was little evidence that this improved any important code metrics, and even some evidence that it actually made things worse, but the longer or deeper version violated someone's arbitrary list of Code Smells That Are Bad so it had to be fixed.
A recurring theme here is taking the essence of a reasonable idea that might be useful in some circumstances but then applying it with an absurd degree of rigidity and scope without regard for the cost-benefit trade-offs being made. XP advocates even made this the centrepiece of their philosophy, though XP was born out of a project that was hardly a great success...