I thought most of these applications start out small but they're nowhere near rock solid and haven't been optimised for speed. It just gets the essential features in the hands of the people who need it and works just well enough to be useful.
The article has an anecdote in it where the "better" guy has grandiose ideas about wanting to make a perfect system that always does the right thing, even at a huge increase in implementation complexity.
In that specific case, not having to restart system calls after an interrupt. I've always thought the "worse" guy made the right choice by shifting the complexity out of the core, because we should deal with each problem in the place where it's most natural. There's nothing wrong with requiring users to make and use (or only use) a wrapper that deals with that complexity in one specific way that is right in the given situation.
As I think about it more, it makes a lot of sense. The only people willing to put up with something flaky are programmers. For most people, it can do little but it has to be reliable.
> I’ve always told him that his penchant for trying to argue any side of a point would get him in trouble.
Have you read the 4 bullet points of the worse-is-better philosophy, in the beginning of the essay?
It could be fast by virtue of having a simple implementation but that isn't a given. Sometimes getting speed is complicated, especially on modern processors.
"Worse is better" implies lowered quality.