I wrote something like this a while back: https://github.com/nakajima/sinatras-hat It's no longer maintained, but it was fun to see how many assumptions I could jam into one framework.
As a heavy user of twilio (I work at groupme.com, we're entirely text message based, and built entirely on twilio), I'll say that every time we've broached the topic of international SMS, they've always cautioned us that it's experimental, and so we've explicitly marked our product as such (USA only for now).
That's not to say that we don't want international bad, but we pretty much trust their judgement as to whether or not they say a product is ready or if it ain't. Twilio does good work, and they're amazingly responsive to developer requests/feedback.
It's definitely faster, though I don't have any actual numbers (sorry about that). Developer performance has increased significantly though, since we we're no longer stuck in "step-state" hell.
It seems to me that the patch wasn't for "GitHub, the EngineYard client", but instead, "GitHub, the Ruby community resource", just as they support JRuby, Rubinius, and Rails development.
If you operated a site that EngineYard saw as a valuable resource for the Ruby community, I'm sure they'd help you out in whatever way possible as well.
Traditional object oriented programming is certainly easily at first, especially to those with a strong background in it. Unfortunately, in every app I've ever worked on, there's a dissonance between OOP and the browser environment that causes things to break down, at which point it becomes incredibly difficult to salvage without a re-write.
After working on some really complex JavaScript applications, my opinion is that the approach Yehuda's advocating in this post is enormously helpful when applications start getting complex, both in terms of the DOM as well as the behaviors that apply to them.
The advantages described by the author here are the same ones you always hear in discussions about the benefits of unit testing (bugs are caught sooner, you feel better about your code, etc.)
The real benefit to unit testing (at least from my experience) is that it encourages you to write better code up front. By thinking in terms of the smallest possible units, you don't bite off more than you can chew. As a results, your code tends to be more decoupled, more modular, and more logical (unit testing helps you organize responsibilities in your code).
For this reason, even if I had to delete every test I wrote after I made it pass, I'd still write a failing test before writing any implementation code. Of course I'd much rather prefer to keep my test suite, since it does provide the benefits discussed by the author. While no amount of unit tests will reveal every bug in your code, the quality of code I've written after writing a failing test first is vastly superior to code I've written sans-test.
Your mileage may vary, but if you haven't tried it yet, I suggest you give it a whirl.
Why not consider making it easy for the confused to ask for help? And treat them with respect when they do. If you don't create a little confusion, it's unlikely you've built something remarkable.
I think it's an interesting way to look at things, but ultimately flawed. When confusion exists, there are many ways to alleviate it. Facebook takes the "blank slate" as an opportunity to actively educate the user. So does 37Signals (http://gettingreal.37signals.com/ch09_The_Blank_Slate.php).
These things may not turn "n00bs" into power users, but they'll at least reach a level of proficiency where they feel comfortable. That's the crucial first step. It only takes a few of them to advance to the next level (harnessing their understanding of your design to think of new ways of applying it) to make things really interesting.
I know smart programmers who are gay. I know smart programmers who are straight. It's foolish to think a sexual orientation would influence one's ability to program well.
Also, just because a discussion has never taken place before doesn't mean it's worth having.