Avoidance of DRY. This has crippled so many projects at my various employers. Bugs end up replicated throughout and fixed piecemeal over time because no one remembers where the bug got copied to. Or if it even was a bug in the other places! The original may still be correct but the copy may have been insufficiently changed, for instance, but after a few years no one is certain what was the original (good version control helps here). Current employer is about to embark on a massive copy/paste project (literally, that's the plan) versus properly parameterizing the existing system so that we can reduce the current dozens of copies down to a few manageable copies (where things are too different for mere parameterization changes).
What I've pushed for is simple, regular refactoring. Build it into whatever your release cycle is. Sprints? Every sprint involves a cleanup effort, doesn't have to be big, but something. Kanban? Try to make sure that X% (measured over some period of time) of your work is cleanup. Larger release cycles? Do the same thing, it doesn't need to be much but it needs to be constant. You skip it once, it's like skipping the gym for a week. The habit is broken, good luck getting back to it. And it's worse here, management will see an apparent improvement in output (because you skipped that cleanup for a reason, to achieve some other release goal). And it will become deprioritized.