That's great, until your huge refactoring introduces a new bug.
You can always make sure you've got some legitimate reason to have done the refactoring/redesign. I got away with rewriting a section of code that the owner of the company had cordoned off with comments like "DO NOT TOUCH, YOU CAN'T MAKE THIS ANY FASTER" because I made it run about 10 times faster. (Honestly, how can you ignore that kind of comment if you like programming?)
I checked in a bug fix (with unrelated speed improvements included) that introduced another bug, but also dropped application CPU usage from 75-100% to under 10%. The owner was initially pissed, of course, but I fixed the bug I introduced in under an hour, and showed that it was still a lot faster in addition to working correctly, and in the end the only reprimand I got was, "well, don't do that again without asking."
For the next few years I kept replacing bad code if I had to touch it, and, no, I didn't always ask first. I was more careful about testing my changes and (since the standard development model at this place was "seat of your pants" anyway) I rarely had any issues because of it.
Refactoring bad code is only scary if you're afraid to take responsibility for the code you put out.