But to go so far in the other direction as to denounce all criticism is a huge error.
Either way, my take away was that honest feedback and delivery/tone are orthogonal. You can be harsh in your feedback/criticism/expression-of-opinion, or you can do so in a way that disarms the other and is trust-building. The former is more likely to be ignored or misinterpreted, the latter is more likely to be understood. (The article presupposes this, and I agree. And one person's ability to take harsh criticism well does not translate to people receiving harsh criticism from that person also having the ability to take it well.)
If and only if you cannot find a way to convey your feedback in a trust-building way, the author asserts that your will be counter-productive in helping the other. Thus there are practical benefits to remaining silent, including: save your time/energy, not risk burning a bridge, not pointlessly inflict emotional harm (ok, the last one is not so practical as it is considerate).
But that's a very specific and unlikely circumstance, and the author explains in the article many simple techniques not to find yourself in such a circumstance.
One powerful set of words I have found when I disagree with someone's viewpoint or find what I perceive to be a weakness in their work is to say.
"Hmm, I like what you said X and Y, but I keep feeling like we might be able to figure out a better way to do Z. What do you think?"
Acknowledging what was good and attributing it to the person, but suggesting an improvement to what was less than good and taking partial ownership for the solution.
I fully support the idea of discussing a problem, but the key term here is discussion. Sitting around talking about how terrible component Foo is because it's obvious to even the most casual observer that it has not a single redeeming characteristic is strictly demonizing.
For me, it's all about the community. Recognize that every program we criticize almost certainly had someone pour a ton of effort and thought into it, and use that knowledge to temper your criticism. Make it a learning experience for the original author, and strengthen your team/organization while you're at it instead of tearing down people in the name of improving the project.