It is true, sometimes the reasons are not good ones. But, if it is in production, one should assume the reasons are good ones, there's already some evidence. The point is mainly that the burden of proof is on the reader to demonstrate the reasons are not good before modifying it... especially because you're right: code smell is the default product of time. We have to be careful about assuming that code smell indicates something is wrong. My couple of decades of experience is that people assuming reasons aren't good and jumping into modifications is a bigger acute problem than being more conservative than necessary. Accumulating the tower of abstractions is no doubt a problem, but it happens more slowly and is caused by a multitude of bad practices, it rarely breaks production or causes downtime, unlike refactoring too eagerly because of smell or opinion rather than demonstrated necessity. It is indeed a fine line, I completely agree!