As I understand it, this all goes back to the original writings / theories / practices that "Worse is Better" was a reply to, which encouraged a "too theoretically pure" way of writing software: Everything abstracted away, generalised, (theoretically) infinitely flexible, etc -- at the cost of code complexity that in practice often turns out to be unnecessary for the vast majority of use cases.

In that sense, every more or less radical simplification that sacrifices some of those fine (theoretical) advantages for simplicity can be said to be an example of "Worse is Better". Because what "Worse is Better" means is just that "theoretically 'worse', but much simpler code is actually better than theoretically 'better' but much more complex code". It's "worse" vs "better" on all those fine more or less theoretical dimensions against "worse" vs "better" on the single dimension of code complexity / simplicity.

So I'd say this article, which was all about how a radical simplification of the code -- sacrificing the (unnecessary) generalization and flexibility they'd first tried to build into it -- turned out to bring a lot of other practical advantages, is a prime example of "Worse is Better". As I understand it.