I know that sounds strange coming from someone who does org cleanup for a living. But chasing "clean" for its own sake is how cleanup projects lose credibility.
Every mature org has one of these: a Visualforce written eight years ago as a workaround for a Aura limitation, by someone who left the company years ago, doing something nobody fully understands anymore. It's ugly. It probably violates every best practice written since. And it hasn't caused a single problem in years.
That page loads fine. Nobody complains about it. No test fails because of it. It sits there, working, silently, exactly as it has since before half the current team was hired.
If you put that on a cleanup backlog next to the sharing rule misconfiguration that's leaking records, or the flow that's randomly failing on 2% of records, you've made a prioritization error. One of those is costing the business something real, today. The other is costing you nothing except your sense of order.
Cleanup isn't a tidiness exercise. It's triage. And triage means the question is never "is this messy," it's "is this messy thing causing pain." No pain, no priority, no matter how much it offends you as an architect to look at it.
The org doesn't need to be clean. It needs to not be losing you money, time, or trust. Sometimes that ugly Visualforce controller is the least interesting problem in the building, and touching it is just an expensive way to feel productive.
What's the "ugly but harmless" thing in your org you've learned to just leave alone?
Book a free 60-minute Salesforce Technical Debt Audit: a score for Usability and Build Quality, and your top cleanup priorities.