The pain comes in when the upstream project decides to refactor the code in a way which forces you to completely rewrite your patches.
It should be noted that the situation where you intend to fork and maintain the project, this does not apply, and by all means make your changes. In the case where you intend to update, this pattern will help you avoid the pain.
If you do not intend to fork and maintain, then do not fork and maintain.
Is that what you are saying?
The way I see it there are there levels in a good stack:
1. CORE 2. MODULES 3. APPS
Ideally, the thing should be extensible enough that the module writers can respond to changes in the core but keep their own API backward compatible. There are fewer modules than apps, and there is only one core.
So I think the whole argument isn't black and white, it's a matter of degree! Things have to get done, and sometimes things change. That's the only constant, you know :)