There's a tricky problem that comes up in teams. A "bad" developer can hack and slash and appear to implement new features in a certain amount of time, and a "good" developer who takes the time to do everything right may actually produce less of obvious value in the short term. When approaching software restructuring, you have to make damn sure that your management chain understands the importance of the refactoring and can evaluate the time you spent for its actual worth. If your organization uses "metrics" or other weasel words to examine productivity, tread carefully.
It's also worth noting that even if you believe you know how to improve/simplify/whatever, it may be worse than you think and sometimes you don't figure out the extent of the complexity until days have gone by.
This, like many things, is a trade-off and not a set rule. In brand new code, by all means make it small and pretty and documented and whatever else would win it an award; but in established code bases be smart about what you "fix".