The thing is that most open source software was designed for use by engineers for engineers and doesn't have a success criteria other than 'makes problem disappear'.
formal usability testing is irrelevant on such things so stop muscling in your own concerns and slating them for a job done.
How is that so? A pretty standard part of usability testing is say heuristic evaluation. You pick the heuristics applicable to the target audience - engineers, like be accessible through CLI. No response means the app executed without problems, man doc etc and test. Usability != pretty interface.
In fact, sometimes you might not want a beautiful interface, because you want people to get the job done. I think the issue with the original article is that it paints broad suggestions so it is easy for me, you and everyone to argue their point.
What about "makes problems disappear with a minimum of effort"?
It is true that powerful systems require some learning, but there also are a lot of things that programmer's would not have to learn if UIs were better.
As an example, consider the time wasted to learn the idiosyncrasies of the various Unix tools. Standardizing simple things such as the way to query a program's version (-v, -V, --version, probably others), or the features of the regular expression grammars of tools X, Y, and Z would have made live quite a bit better. And yes, it would break existing code, but sometimes, the price of change is worth it for the benefits it brings, accumulated over the years.
formal usability testing is irrelevant on such things so stop muscling in your own concerns and slating them for a job done.