This is an exemplar from your comment that leads me to this observation, you write (first quoting the author):
""Writing X11 programs with xcb and proper RPC APIs like SUNRPC or Thrift should be more than good enough."
This 100% misunderstands why dbus is used. The first goal of dbus is not to send a message from process A to process B; it's to keep track of processes (help A find B, have them each know when the other goes away). The messaging is important but in many ways secondary."
I would suggest that it points out a 100% misunderstanding on remote procedure calls. Your defense of dbus asserts that its primary function is to 'keep track of processes' which would suggest its name should be 'dlocate' or 'dmonitor' but its 'dbus' because most of the traffic on it is like a 'bus' where data goes from point A to point B.
The original author points out that all of the 'features' of dbus which are not directly related to interprocess communication could have been implemented on top of the existant architecture. People have done that, they called them 'location brokers' back in the 80's. And what the folks who invented dbus missed was all of the research about what makes for good network protocols like Andy Birrell's seminal paper on the RPCs or work done at Sun, Xerox, Apollo and elsewhere.
You wrote:
"Overall, the article doesn't understand the big picture of why all this new stuff was needed."
But that wasn't what the article is about at all, it was asking the question why is all the substructure re-invented every time? The author rants at how Linux's tendency to constantly recreate every wheel every time is hugely destructive and wasteful.
The real problem, which is not mentioned explicitly but I suspect is at the root of this entire rant, is that it is infinitely easier to create in Linux than it is to fix. When there is a problem with the way desktop events get delivered you can either fix the broken system or you can invent an entire new one. Too often, for reasons which are not well reasoned or supported, people create. I see three reasons for that:
1) It is hard to have two smart, outspoken, and opinionated people work on the same piece of code.
2) If you can choose between "the person who fixed Y" or the "the person who created Z" on your resume, inevitably people lean to the latter.
3) When all you want is feature 'X' which should notionally come from system 'Y', it takes less work to create a new system Z which does all the things you personally need from Y and has X as a new feature. Than it is to understand all of the users of Y and what they need and then incorporating X into that.
And lets close with this bit, you wrote:
"if someone could show up and make the desktop UI stuff behave well with the "unix way" they would have done it."
They have, Motif and SunTools were both such then, Windows and MacOS are examples today. I think you could successfully argue that Linux is on the brink of proving that Free Software is a fundamentally broken model of software development, and use the window system as the exemplar of that argument. The closest counter example we have is Canonical which, as well all know, is well loved by all folks who work on Free Software.
The linked rant boils down to 'Linux sucks because nobody can be bothered work with somebody else's code.' which is of course an exaggeration (but what are rants if not emotional expressions of frustration through hyperbole rhetoric?). If you cannot see the danger that poses to its lively hood then yes, you are by definition clueless.