Surely this is more of a misunderstanding about what `Backbone.Model.extend` actually does. I wouldn't necessarily call it "strange" behaviour.
When you extend a Backbone model, it adds the new properties to the class prototype. In the example, `myClass1` and `myClass2` share the same counter, but not for the reason that the author thinks. It's because they share a prototype chain. The fact that `counter` is an object is a red-herring; the same behaviour would occur if `counter` was a number.
The events mapping should not be stored on the object prototype - this will cause all instances of EE to share the same collection of events.
`this.events` should be assigned inside the class constructor, or - as is the case with many other EE implementations - lazily created inside the prototype methods (making inheritance easier).
I have started using this fairly extensively in production.
First of all, I'm very impressed with its performance; the fact the it makes very aggressive optimizations to any DOM-related code removes one of the biggest inefficiencies in UI development.
It not vastly different to a typical Angular workflow, though is perhaps less opinionated. Like Angular, it encourages you to be very modular, and think about UIs in terms of components. Ultimately, this leads to very portable code, much in the same way the Angular directives do.
If you are keen on data-binding, then it's a slightly different approach: React treats the UI as a representation of state, so any change to state triggers a re-render. (Thanks to DOM optimizations, this is not as expensive as it sounds, but it takes a bit of getting used to).
I'd say that the biggest difference to Angular is that it doesn't proclaim to be anything other than a view layer - you still need to provide data modeling, routing, etc. (Incidentally, it works very well with Backbone). It just depends whether you like that idea.