If you WEREN'T a prototype user (MochiKit here), you had to deal with their Object.prototype extensions. All frameworks at the time had specific checks to handle the prototype.js extensions because it was the most popular framework and (like jQuery today) people would just add it to your pages. Unlike jQuery, it caused things to blow up in not-immediately-apparent ways.
Part of the difficulty with the dogma surrounding the issue of whether or not it's ok to extend built-in objects comes from extrapolating a set of guidelines and rules for library / framework developers to everyone else. There's real value in libraries not extending built-in objects simply because they can't make any real guarantees about their execution environment and shouldn't force their customizations on all code in that environment.
I think part of it comes from the most vocal (and probably most respected) JS developers tend to be library developers and their guidelines for themselves and each other tend to get misconstrued as general guidelines for JS development.
When you're developing in a known execution environment, I don't see any particular issue with extending natives.
One of the best features of ClojureScript - the freedom to extend natives fearlessly. The ClojureScript compiler automatically namespaces all symbols preventing the kinds of excruciating conflicts you would encounter otherwise - whether from browser evolution or other libraries.
The trend I see is that the "extra-native" features that these DSL style frameworks were adding are now being taken care of by compile-to-js languages (CoffeeScript, ClojureScript). The question is whether this is advantageous. Certainly it removes a big dependency on the client side but this is at the expense of an extra mental leap during development. I think we'll start seeing big advantages when the debuggers work properly (http://www.meetup.com/Coffee-Script-New-York/events/41391392...).
I had a conversation with jashkenas about this - I don't think source-mapping alone will ever be enough. For the debugging experience to be ideal you'll want things like locals inspection as well being able to evaluate expressions during the debugging session. Perhaps tools that into WebKit's remote debugging protocol can get us closer, http://trac.webkit.org/browser/trunk/Source/WebCore/inspecto...
I stopped using MooTools almost 7 years ago. My rationale was this: if I can't trust what the this variable is in an event, because of the framework, the framework isn't worth using.
Mootools completely confused me with the constant alteration of what this was referring to depending on event or context. But in jQuery usage of this was (and still is) very straightforward, so I switched.
It's no question of extending objects or of prototypes, but it's just about as confusing, if not worse, when an object/prototype is extended without the programmer's knowledge.
I know your article is not really related to your title but i'm sorry when your implementation stop working on new browsers your kind of "breaking the web".
That is not to say that you can't do a good native augmentation, but they certainly did not at first.
