One refactored everything endlessly to a fault, wrote tests for everything and emulators for every external piece of hardware.
The other rarely/never refactored and was focused on ends-justify-means functionality.
They hated each other and progress was very slow because they could not work together at all.
My two cents is that all products of engineering are temporary. Software (and hardware) are not eternal. What you write today you will eventually become obsolete.
Your entire app will eventually be re-written. If not by you then by your competitor who takes you out.
There is no such thing as perfect or optimal code because what is great for now won't be great for tomorrow.
With that in mind, good refactoring is like good math. Taking a long and complex system of code and replacing it with something functionally better and far simpler and easy to understand.
Bad refactoring is just moving things around for "understandability" or in a lot of cases one developer rewriting something in their own idiosyncratic style because they don't understand the style of the programmer before them.
And the final point is don't be afraid to rewrite the entire system if you have that ability.
Since the development process is about defining functionality as much as enacting it, once you have a finished application, you can re-create it much faster and simpler than it was originally written.
The Apollo missions got to the moon and back with 145000 lines of code you don't need 20 million + for your web app.