A good Refactoring can transform a kludgy WL code-base into a thing of pristine coherency but how to do so consistently?
In functional programming languages refactoring is considered a main activity. Ideally we derive a new language that fits the problem we want to solve. (E.g. see the preface of "On Lisp" or the article "The Roots of Lisp".)
This observation obviously does not help when we inherit code, or we have to adapt or re-design old code (because of changes in the language or our understanding).
Big Ball of Mud
The article "Big Ball of Mud" gives well researched diagnoses and prescriptions of when and how to do refactoring. It is a good answer of the request:
[...] transform a kludgy WL code-base into a thing of pristine coherency but how to do so consistently?
Using that article, we identify how we ended up with the code we want to refactor, and then utilize the given prescriptions.
For MSE discussions that include using software design patterns in Mathematica / WL see these answers of "General strategies to write big code in Mathematica?":
Leonid's preamble to a large answer,
I have used the patterns in "Big Ball of Mud" to refactor large scale air-pollution FORTRAN IV code (that was fairly large) into components of an object-oriented C++ framework.