I think Alan makes several points that were missed, and you make a good point but conclude the wrong judgment.
If the software developers do not include domain experts the project will produce drek. No question about that. But, end-users are not necessary domain experts. Most users do not know how the automated processes of their software work, and could not tell
you the requirements on a replacement. I have often gone into replace a manual system and rather than simply implementing the current user's process, have provided a solution that required 1/2 or less of the effort of the original manual system. So domain
experts are always needed, but not end-users per se.
The other point is that he is promoting a different way of structuring software development, so "reality" is not so important to him. He wants to change that. The current processes that leave mediocre programmers in charge of what the software does, is not
a good solution, so why defend it? I certainly know that sense of helplessness that drives that lament. Being in a job where you feel you have no abiilty to make things better is very frustrating. That is the death march he mentions as the current status
quo in many organizations.
I would expect that he would say he is not the right person to design an OS. He is not a good person to design the scheduler, the DMA support, and so on.
He would probably also say that his ideas of how the OS should behave are no better than anyone else's. We all have ideas for what the OS behavior should be, but that design needs to be more than just a bunch of ideas. A house I once saw as described as "The
architect had 5 good ideas here, unfortunately he used all of them."
What makes many great products stand out is that the set of features and approaches to the problem work together and are not just a bunch of separate features thrown together. For example the Apple word processor Pages does far less than Word but is more enjoyable
to use because all the features work together and the overall design appears well thought out in advance. The same is true of many other good products. WPF is an example of software that has a very well thought out interface to its user (programmers). If
you threw 20 application programmers in a room they would almost certainly never have defined an API as good as WPF.
The best project I ever worked on in terms of low stress, productive process, and satisfactory result, was a project where we wrote the user manual first and the code second. We defined at the level of the user manual exactly what the software was to do.
Then coding the software to do that was much easier, and there was no indecision on what any features should look like.