Do you like employees who like to refactor code?
However, the refractory is self-opinionated and buggy, also slow down the progress of the project.
Re-factoring may increase (in-/en-) or decrease (de-) it. If it becomes self-opinionated, buggy and slows you down, that likely increased. Textbook refactoring usually trades amortized length for complexity, not the other way round, but that’s okay because they take it from a “completely flat code” perspective.
So it really depends on your coeffs in that formula and ideally should be managed by someone who tracks these indicators. Not by a passer-by whose taste was offended that day.
* google has some definitions, but I used the term freely
I’m confuse though why you don’t just say refactor. This just reads like you redefined “refactor” to be adding layers and “defactor” to removing layers.
Textbook refactoring, changing a program internally without changing it external. It’s up to the refactorer to choose what to apply.
Applying a refactor is not only adding FactorBeanProxies. It can, and must be, used to remove parts as often as adding them.
If your coworker is refactoring code and making it buggy and also making it harder for the rest of the team to understand, that might be a bit of a problem. When working in a team, you follow common conventions you agree on for a reason.
Rebuilding something for the sake of making it say 5% cleaner is often a bad business decision. No matter how well you think you're testing something, any non-trivial system is going to have some edge cases and crazy things that messing around with is going to cause you headaches.
But if a system is a complete fustercluck and long-term progress is harmed with how convoluted it is, then spending a lot of time refactoring it seems wise.
A good engineer has the judgement to know when tinkering with existing code is the smart thing to do.