Hi, Sam. I agree with you on more points, than you think - almost on all. Just some details and differences more:
1. I have no problems at all with code quality issues. If I'm told "you code quality is insufficient, it should be improved this way" I am either improve code (usual), or, if I totally can't do this, step back. Actually these events often are quite pleasant ones, since I could learn something new in my programming skills from them (many thanks to Tim personally regarding this, working with him was a honor). Of course, I am not a match to Tim Hunt (or some other Moodle core devs) when it comes to the code(or design) quality - but I've seen much worse in the Moodle core. And there were cases where I pick an idea from core developer and take care of debugging and implementing it. I agree with that barrier and going to take it if I can do this at all. After all I just personally hate to do low-quality things. 
All I need is a hint how this could be better.
I also find out, that in practice it's not unadequate code quality that stalled code going to the Moodle. Developers usually could relatively fast tell that code is of low quality and write about it. It's when the code is finally of good quality that thing is usually stalled, since developer now feeling much more responsible and want to be very sure it won't hurt anything, which is much harder to find time and concentration for.
2. I also respect Moodle core devs right to make decisions, who thing should be implemented - that's their project after all. There were cases where I would prefer another way, but do as I was told by core devs. Or even one, where I agreed to do things as local mod, but write a refactoring to concentrate code in one place, which costs moodle about a hundred of strings of code. No problem with advance agreement too.
3. And there is just this problem: "this is a good thing to have, but I'm too busy so wait and write more good code for Moodle in the meantime (sic!)". This is the barrier I can't take, the only really hard one.
And I could first-hand assure you, that it is not at all easier thing to do when you have good code for Moodle quiz/questions that isn't lined up with OU objective, especially last year. 
You could just look on MDL-20251 (how long should we have that dumb interface that moves category only one step away for one page reload?!) or MDL-6340 to see that those words are not empty. All agree this is useful thing, reported code quality problems are fixed - and we almost could celebrate year's anniversary of this code rotting on the tracker.
4. There are two differences more between large University-initiated installation-development and teacher-initiated one:
4.1. You have a staff working directly for moodle development, who could maintain you patches all the way until they are accepted. I have none, my university didn't get me specific time for this development (unless I use it as a task in a course I teach). All work is done in my free time. I am just a user - who happens to have programming skill - who are willing to spend some take to make system he works with better for himself and others. So the problem of upgrading my Moodle core code while it is waiting is far more important for me, as I have no special time for that. I'm already looking uneasy about upgrade all this for 2.0, but having this for 2.1 etc is a real shudder. Sometime I would just give up, since it would be easier to work with dumb interface than support it's improvments personally in free time.
4.2. You example about site administration is also a good one. University-initiated development look for admin site first. I am admin and a teacher, but as so I know that teacher work done much more times than administring, so I am concerned more with question editing issues or bulk activities editing ("You are going to use new computer lab this year! - Great, now I have 30+ quizzes to manualy edit IP filtering!!!") for example.
5. I am too sceptical about "more receptive", until, at least, there will be some visual stats for Martin & others to look on how good - or bad things going in this area. And to anyone read this long, a real proposed thing: Helen (supposedly Community Manager), Anthony (supposedly Contrib Coordinator), I, Davo and any other interested core/external devs discussing and planning how this stats could be done, what tracker enchances would be needed. A separate project could be good, since then we could have special states and resolutions (like "bad code quality" etc), which would make stats much more informative. Or at least some custom fields like "has external patch", "last external patch submission date" or "core dev opinion of the patch (list)" etc. We coudn't get things moving without a picture of what's happening and how it evolves.
P.S. Moodle main development problem is how good (compared to competitors) it is. It just doesn't have enought reasons to try hard to be better for it's users. They have no choice anyway for now.
