> but makes the app just a little less organized and understandable in the long run (bad)
This sounds like normal code-rot; code is changed to achieve some particular goal, but budget isn't allocated for the requisite refactoring. I personally prefer that refactoring opportunities are seized whenever they appear; managers with budgets don't usually agree, for understandable reasons. Eventually you end up with a hairball that can't be refactored, and has to be rewritten.
Whether a change should be made at all, whether to go ahead and refactor there and then, or how long to postpone the refactoring, are all business decisions that have to be taken by the person that manages the budget.
This sounds like normal code-rot; code is changed to achieve some particular goal, but budget isn't allocated for the requisite refactoring. I personally prefer that refactoring opportunities are seized whenever they appear; managers with budgets don't usually agree, for understandable reasons. Eventually you end up with a hairball that can't be refactored, and has to be rewritten.
Whether a change should be made at all, whether to go ahead and refactor there and then, or how long to postpone the refactoring, are all business decisions that have to be taken by the person that manages the budget.