I'm of the strong opinion that if your code is encapsulated, it's pretty okay for it to be entirely shite as long as it works.
If someone needs to maintain it, and that someone isn't you, it's very likely they're going to understand your shite stream-of-consciousness code much more easily than your beautiful, elegant code that has had all of the thought process refactored out of it (but refactoring is a very important tool).
If your code is less clear after refactoring than before, you have gone a step too far in refactoring.
Your goals when refactoring is removing useless bit of code, make the code understandable without comment and remove duplication.
That is the last step that generally requires introducing additional abstractions layers and where stuff go wrong. Too often refactoring books or articles give examples of how to use refactoring technique, but for the sake of being readable, the examples rarely really require such refactoring in the first place.
But yeah, at the end of the day I also prefer a hackish piece of code that solves the problem than the same "refactored" into conceptual art.
I'll happily accept code that's a product of this mentality (+ tests) over jargon-ladened "zen" code.
We too often forget our code sits atop a stack of compounding encapsulations we'd all find horrifically disgusting whose only true merit is that it actually functions.
If someone needs to maintain it, and that someone isn't you, it's very likely they're going to understand your shite stream-of-consciousness code much more easily than your beautiful, elegant code that has had all of the thought process refactored out of it (but refactoring is a very important tool).