The ‘better interface’ comment about fighter planes and the ‘better GUI’ comment about OS’s both miss the fundamental point of WorseIsBetter in roughly the same way.
The actual product is worse. E.g., the Russian plane, flown by a competent pilot, will typically lose to the German plane flown by a competent pilot. It’s interface won’t save it in a dogfight. But the worse product is better for the targeted application. How a given thing fits in the real-world context that matters, not the thing itself.
So long as thing X passes the minimum acceptable requirements for things of its class (the plane flies and shoots, the OS runs useful apps), it will beat thing Y IFF the variables outside the scope of things of its class but relevant to how the thing is used in its target human context are in X’s favor.
To finish the example, the context was winning the air war, not making the best plane. The rooskies won the air war because their plane was good enough as a plane, and their solution was better fit to realities external to pure plane quality - namely pilot trainability throughput, pilot turnover, and new pilot availability. The solution-in-context was better, but the plane was not.
It’s mostly about drawing the right-sized box, but allowance must be made for fuzziness of the critical variable definitions - in this case, ‘good enough plane’ and ‘critical pilot turnover rate’.
Another way of looking at it: avoid falling into the trap of thinking that the key tangible component is the only thing that matters, when the thing has to be used in the wild.
Unforunately, this has nothing to do with Steve M’s point about Good v. Great.
PS - Steve Martin really does have mad skilz - check out ‘Picasso at Lapin Agile’ if his popular stuff makes you think otherwise.