Agreed - and note that this principle is in tension with the junior/intermediate (heck, even senior) urge to make things "easy to change" by just making everything abstract and configurable. ("See, now if we want to do it this other way in the future, we only have to flip this bit!")
I still haven't found a pithy way to describe the limitations of this principle. Obviously, frameworks are helpful and also fail this principle, so even this principle has exceptions. But are you going to be so arrogant to believe your abstract extensible change will be adopted by all your fellow teammates in the future?
I think the core problem is that it assumes you know what part of the software will need to be changed. But you often don't so you end up with code that is too rigid in places that you need to be flexible and too flexible (i.e. complex) in places that don't need it.
I still haven't found a pithy way to describe the limitations of this principle. Obviously, frameworks are helpful and also fail this principle, so even this principle has exceptions. But are you going to be so arrogant to believe your abstract extensible change will be adopted by all your fellow teammates in the future?