An important context is the use case. Grossly speaking, business applications tend to have a shorter lifetime and faster cycle time than system code like, say,

An important context is the use case. Grossly speaking, business applications tend to have a shorter lifetime and faster cycle time than system code like, say, the Linux kernel or gcc. So the cost of refactoring in the latter case is amortized over longer timescale; when you have rapid business needs it can often be better to just pmake the change in two or three places and move on because in a few years the whole thing will be replaced. We all know of exceptions to those examples (quick-and-dirty code that survives decades later) but I think that's the way to think about it.