The production of a really good UI is a process of trial and error. The usability is not something you can work on without having a large set of humans outwith the design process to pick up the ball and run with it. If you are a programmer, you have preconceived ideas how a system will operate (which are 100% correct in your own mind) and you will work towards that target.

A good, intuitive system is the product are many cycles of design, implement and test. While prototyping through may bring about a very quick piece of software and hardware, it still takes time, limits you to the framework you are implementing in (either in terms of software restriction, or the time to implement framework to cope with the new concept).

If you work with a piece of paper and get the end-user to "click the button" on the piece of paper with actors taking the roles of modules and components, it may seem a little silly at first, but you have the means of many cycles of POC within the same session. How many software prototypes can boast multiple iterations and vast design changes within the space of a single hour.

Carolyn Snyder's "Paper Prototyping" is an incredible read. Well worth a look, because it avoids completely the aspects you discuss about the real restrictions, and deals wholly with what the end product is like to work with.

E.g. the redesigns here are really nice but I have reservations straight away about the size of the components. The mockups look great on my 24" monitor, but I'm concerned if look at them on a screen the size of my N900 then I would quickly get weary of the them (just a case example - not a criticism, but something that needs consideration).

I'm digressing! But my point is designers should not be restricted by what a coder can do and vice versa. And above all else the HCI champion should have the casting vote