There's simply too much to respond to here to do it well, unfortunately. But thank you for writing the response.
I can see we haven't met on the same understandings, though.
For instance, no, I'm not suggesting Witnesses should be Code Monkeys -- but the ramifications of what I'm saying -- that Witnesses are the ultimate gatkeepers of the code -- may be that they should be Code Monkeys -- that is if a Witness believes in Upgrades. If a Witness does not believe in Upgrades -- then I can't imagine them reviewing much new code. Further -- if the Witness wants Upgrades but doesn't want to review code -- that's fine -- and it's even better as long as the Stakeholders understand. Incentives in Witness positions to have their operators do as their Stakeholders would wish should cause the right balances between Stakeholders and Witnesses over Tendencies to Upgrade or Not, and for what reasons.
In short -- I'm not telling anyone to do anything. I am suggesting that the balance of governance will work itself out. And I am suggesting that some prompting, such as posts like these, will help it become worked out faster. Really, it wouldn't make a difference if I had told you and others what to do. Like you said, you don't work for me and vice versa. If I had, you could ignore me, or not. On the surface, like that, DPoS doesn't really care.
I'm not entirely sure how you meant "the balance of governance will work itself out". But when engineering a piece of software or a machinery, we never let it work itself out. It's always designed based on our best understanding of how it will function. If it functions differently from how we predicted, then we tweak the design continuously until it does work the way we want. That is why computers, bridges, trains, etc. work quite reliably most of the time - because there was a certain process used when creating them.
The classic idea of democracy with division of power and the public voting for this party or that party was developed as a social technology that performed better than previous social technologies like feudalism where the rules of the game didn't allow most of the public to change the rules of the game. Blockchain as a social technology, and Steem as a particular implementation of it, seems to hold promise for a massive upgrade of the currently established social technology. One of the promises it holds, to me, is in changing the way things are done. If we use processes that are used in the world of technology and engineering, then reliable solutions will be produced (i.e. there is a massive track record of reliable solutions already produced using these processes).
It's a different way of thinking. The governance process has to be designed so that the needs of everyone get met. It's not about striking a right balance or anything like that. The best engineering solutions often times are about changing a trade-off to a situation where we have all the desirable things we want and the undesirable things are absent. It's about creating a solution that repeatedly performs the way we want it to perform.
How can this be done, in practical terms? I think the first step is to create a procedure for doing hardforks. If the procedure works well, we will see the results in the form of smooth hardforks happening and working the way we want them to. If the procedure doesn't work well, there will be downtime, issues and a lot of unpredictability when doing hardforks. If the latter is the case, then we will tweak the procedure for doing hardforks, and then measure how well it performs.
This is akin to scientific experiments - when a scientist performs an experiment, he or she has to write down the steps for others to be able to reproduce the experiment and get the same results. This is currently totally missing from the way our society governs itself, and I think with blockchain technology we can demonstrate how it can be achieved, and Steem can be the first example of it.