I agree with this. In a large organization, if you have risen to a level where you are being relied upon at a regular intervals, it is imperative that you have a well architected solution that you can readily change and this is where you separate your program from spaghetti code to something useful. Sure, its nice to write unmaintainable junk when toying around, but I to have seen too many codebases where people were just throwing features in without thought and it causes the program to become way too constrained to only a specific problem domain and it becomes inflexible for solving new problems (to the point you have to re-write nearly everything from scratch).
The contrast to this is to put in tickets specifically for refactoring and reorganization, but I've rarely seen that work since they often don't have any sweetener included to encourage e.g. product organization to sign off on the work.
Yeah, it's a shame, I often have to do this type of crap in my off time. However, having a well architected app significantly reduces these types of massive undertakings. Doing it right the first time has its advantages. Then again, weighing it against delivering early and other important aspects has its merit too.
It's just a double edged sword unfortunately that you often have to walk in this industry.
