Code cleanup can mean many things. When talking about architecture, it could be a legit argument that due to requirement changes there needs to be a rethink. But that's not debt. That wasn't a conscious decision made in the past to do A instead of B knowing that B was the right choice, but not realistic at the moment.
When talking about large code bases that have been around, code cleanup is a young person's term that tends to imply they are smarter or know more than the previous set of programmers who worked on it. That's possible, but a bad argument. And it's insulting. Obviously the code has worked for quite a while successfully, so it can't be as bad as it's being made it to be (that's management playing devil's advocate). If it hasn't been working, the schedule should reflect fixing it. Maybe that requires a massive recoding, but maybe not.
I'm thinking of cases where it was a conscious choice. $deity knows that I've made plenty of such decisions in my career - chosing a hacky structure A to meet a next month's release, while articulating to management that after that release, I'll need to redo it to structure B. Sometimes a bunch of high-priority requests took precedence, which made the system stick to A for far longer than it should. I understand that to qualify as both "technical debt" and "architectural issue".
It's not insulting. For one thing, the person proposing the change may very well be the original author. For another, you have the benefit of hindsight and access to information they didn't about what bugs would emerge, which features would be demanded, and how hard it would be to implement them. Of course you're going to see better ways of doing things than were visible on day 0.
Increasing speed and reducing risk for all future iteration is some of the highest impact work you can do; rather than shipping a single feature, you're a force multiplier for all the features developed by your team.
The only time it makes sense to skip cleanup is when you're content to just let the thing run, and don't see any changes in the pipeline.
This. A thousand times, this.
Firstly, there are people smarter than me, it's not insulting, especially if a person makes a real improvement. Or maybe I made a mistake.
Secondly, original designer had to make a decision with limited information and time. Now we have the benefit of hindsight, so coming up with a better one is hardly surprising.
My process often involves creating layers/versions of the code that improve till the stage it's production ready. It might be half a dozen or more iterations to get to production quality for complex code, and the latter versions involve a lot of 'code cleanup'!
This includes things like implementing TODOS, adding logging, and refactoring and refining the concepts, the naming, making the code more dry, better srp and generally elegant code I hope that someone else would be happy to inherit and maintain and extend. That someone is often me!
It's taking something that works, mostly, but has limited clarity and elegance and higher future costs to work with, and 'cleaning it up'. Like a home or worksite cleaning up after working gets you ready to use it or work there productively in future.
I do this in most codebases I work in for awhile as well, when there's clearly need for improvements in dry, srp, conceptual patterns and clarity.
Our industry jargon calls this refactoring, but cleaning up actually relates to other stakeholders than the highly trained engineers, so I will generally call it cleaning up.
I agree with you that newer engineers often want to rewrite existing working things for many wrong reasons - but I think the specific term code cleanup has a place.
I think it's interesting that you've noted it as a code smell for a junior about to wreck a significant amount of company productivity. That's an all too common problem these days as the majority of engineers are junior with less than 5 to 10 years due to larger numbers entering the industry. I'm interested in the 'successful' strategies experienced engineers have used to head this off at the pass in organisations with non technical management who often listen to the loudest voices if they can't truly understand the issues themselves.
It can be in certain cases, but it sometimes depends on the perspective. Abstractions are hard and usually need enough time to think about and several iterations to get right. They are usually much more obvious in hindsight.
Technical debt is all these architectural issues which incurs a long term cost because minimum deliverables had to be met. Also, the first response to "performance" is always gonna be "throw more CPU/memory", not "let spend a month dev-time to rearchitecture." Tech-debt is only getting addressed when hardware can't meet the requirement, "performance" is just a marketing argument to sell it to management.
Prioritizing improving performance for aesthetic reasons, that is because a "low-performance hack job" offends someone's sensibilities, likely means either: 1) the team is poorly lead or 2) doesn't have enough high value work to do.