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 :)
I fully agree that you should always try to contribute the changes you make to a Free Software project. This has not only the advantage of less maintainance work in the long run. It also means that your changes will be reviewed - by people who know the code you're modifying very well. So contributing also means to get a good quality assurance.
However, it makes still a lot of sense to keep a local fork in addition to contributing. And here the author argues too one-sidedly when he recommends that you should do that only for security fixes. There are many other scenarios in which this makes sense:
1) The change may be important for you (e.g. to make the code compile on some strange OS), but not be accepted by upstream (e.g. they don't want to support that strange OS in the long run).
2) The review process, as well as the next release, may take some time. And you certainly don't want to make your own release schedule totally depending on other projects' release schedules.
In the first case, you have no choice but to keep a local fork as long as the project maintainers don't change their mind or provide a better solution.
But even in the second case you'll have a long-term fork, at least if you are contributing regularly. But that's not a bad thing, because everytime the upstream project releases a new version, you can remove some of your (contributed) local changes from your fork. So yes, you'll have a long-living fork, but it will only differ from upstream by the last few patches not yet accepted by them.