Having spent a lot of time deep in the guts of the CiviCRM code base, I'm a little skeptical with the direction you're going with this.

I'm not a fan of QuickForms either, especially since it tucks so much data into $_SESSIONS that it's nigh impossible to figure out what it's doing. Debugging is particularly difficult.

But my own sense is that you're concentrating your effort in the wrong place. The major problems doing CiviCRM development have tended to be:

1. The complexity of the class hierarchy. It takes a long time to understand how dispatch works, or to understand how the query generator works.
2. The interdependence of different parts of the the library. I have yet to do a non-trivial project that didn't require hitting 20 or more core files to integrate new functionality. In comparison: on Drupal projects, I haven't needed to modify Drupal core in years.
3. There still isn't a good packaging model for new functionality, although I understand a bit of work was done for 2.0. Adding UI generally means dropping multiple files in multiple directories. There isn't a simple way for a chunk of code to integrate itself into CiviCRM screens. And while custom fields are much better than they were in 1.x, it's still hard to manage a separate table (although the XML data defs could become this).
4. Scaling is hard. This is where I'm most skeptical, because it isn't clear to me that a Ruby-like approach would be an improvement. Reading your last diary, I'm in general agreement with Joe Murray: pushing some core functionality into the database itself would make it much easier to do bulk operations, and it would likely also make the PHP code easier to understand. I built a large library of SQL and perl code to do bulk operations in 1.x, because it was orders of magnitude faster to do these things outside of CiviCRM in PHP than I could do independently. But that's a lot of effort, and since what I do is fairly specialized, it's not the sort of thing I can put up on a server and say "have at" for people with similar problems. And if we pushed certain core operations (add a contact record, delete a contact record) and had a good set of hooks, we'd have both good speed as well as much simpler client code as well.

If given a single choice, I'd say that packaging is the highest priority, since it would all people to do non-trivial projects that were easier to port between versions of CiviCRM, and would decrease the need some of us have had to fork the CiviCRM tree in order to track and maintain the modifications we've made in a particular version.