Here are a few thoughts here that may help move a dialog forward.  I speak as someone who supports some Ubuntu deployments, as a user, and as an open source software developer who does a lot of work in my own community.

The first thing to recognize is that community engagement is always broken.  perfect engagement is impossible.  Any open source project can always improve that engagement, so if community engagement is broken, that's a relative and not an absolute statement.   As developers we can and should strive for perfection, and one of the strengths of open source software is the interaction that users and developers have.  This allows developers to understand user needs, and users to better communicate problems so that they get the right solutions.

A second thing to recognize is that not all feature requests are reasonable or should be included.  But all feature requests should be considered for further action even if they are not going to be implemented exactly as requested.  A feature request is what we get when a user says "Hey, this isn't working for me."  It takes time to engage with users to better understand needs, workflows, etc.  However ultimately one gets a better product if one does.

So for example, when I look at the bugs above, I conclude that people are defensive of design decisions and less interested in *why* users are requesting this.  If I were managing a project, these feature requests would be considered for further action at a later date, users would be engaged with, with an idea of trying to understand their needs.

Now, maybe after we all talk the answer is "use a different desktop."  Maybe the answer is documenting "Unity was not designed for widescreen displays in portrait mode."  Maybe the answer is working on finding a mutually acceptable solution.  However, with very few exceptions, I don't think it's a good idea to simply say  "this isn't in line with our design goals" and leave it at that.

I have seen this sort of interaction before and it never ends well. 

Of course, Canonical has a moral right to spend their time and resources how they wish.  However, from a community perspective, it might be better to be clear as to whether something will not be fixed on Canonical's dime, or whether Canonical is even unwilling to discuss or accept patches on the matter further.  If the latter, I think a great deal of sales work needs to be done selling the way things are, and listening to users as to shortcomings.

If I were to suggest a fix for this bug it would be as follows:  Change bug reports of this sort to a different category (let's call them UI feature requests).  Let everyone know that Canonical considers this to be outside of what they want to do.  Move requests there.  Let other people review those requests and implement them if they want.  Canonical can then accept patches.  If a feature is not going to be accepted under any circumstances, then work needs to be done understanding why it is being requested, and a mutually acceptable feature request added to that queue.  If Canonical is undecided on this latter category, maybe say so when moving?

The advantage to this sort of system is that when new features are being considered, this same queue can be reviewed and used as feedback.  The features may not be implemented as requested but the needs of the community both to be heard and to have their work flow needs met.

Of course, anything that is not a priority for any developer should be delayed until it is a priority for at least one.