I definitely hate solution number 2.
One major problem I find with OOP is that it is often requiring refactoring. Every time you shove something into an object you actually take away from it.
One thing that greatly inspires me from Haskell is that it does have design patterns, but they are based on category theory. Math is the ultimate tool. I don't think we can accidentally "create" something as richly descriptive for describing the benefits and problems for using a certain pattern.
I'm having trouble understanding your definition of "refactoring", then.
When I refactor, it's almost always to eliminate repetition and make the code more concise. But doesn't the same thing happen in a functional program? If you find the same code twice, refactor into a single function.
I'm getting at the idea of having to rearrange the code inside classes because your original assumptions have changed. Sometimes this involves moving stuff between classes. This is especially messy if the class has any member variables or relies on private functions.
In Java-land, this seems to be the kind of thought process referred to as "engineering". Read the code in any random Spring project, for example.
Personally, I prefer writing simple code for the job at hand, and, yes, refactoring when I find two or more places where the same code can be re-used. And even though I develop mostly in Java, the most "functional" solution is generally the one with the least complexity, and easiest to debug.