Any time you change a piece of code, you need to have a solid business reason for doing so. Right now, at $work, we're doing a complete refactor of our code similar to what you're describing. But, we are taking less than 2 weeks to do so, are refactoring a spike into productionizable code, have a test suite with significant coverage, and we have a project already lined up that needs the refactor. Any of those items aren't true and not only do we not get permission, but I (as project manager) don't even try to get permission because I don't think it would be proper.

In general, I agree that refactoring should be an ongoing process and that it should be built into the schedule. All schedules should have flex that can be returned back to the manager, but can also be used up in refactoring or other bugfixes. If you're scheduling to the bare metal, you're just asking for trouble.