1. "A Clear Architecture". The MVC in Spine is structurally identical to the MVC in Backbone (or MV*, or whatever you'd prefer to label it) ... except for:
2. "Models are Models". Following Rails' lead, Spine conflates the class of a Model with the object that represents the Collection of all models of that type. This makes sense on the server-side, where you have ready access to the entire table; but is a misstep on the client side, where most of your lists of models will only represent small filtered collections of the server-side table. It's very useful not to be limited to a singleton, making it easier to have different sets of the same kind of model with different endpoints (/documents/101/notes vs. /documents/202/notes, for example).
3. "Spine.app". Yep -- Backbone doesn't include a file generator. Some folks like putting every class in a separate file ... others prefer to leave their entire (small) app in a single file. It's up to you.
4. "Dynamic Records". The code example shown here works exactly the same way in Backbone. If you find a model by id, you get a reference to the that record. It's not surprising that changing one changes the other because both are the same object.
5. "Elements Hash". It's been proposed for addition to Backbone, and there are plugins for it (https://github.com/chalbert/Backbone-Elements), but we aren't adding it to core, because it's not a great default. With frequent re-renders of Views, cached elements are likely to be either incorrect ... or they all need to be re-queried every time the view re-renders, which would be very inefficient. `this.$(selector)` is a nicer default to have.
6. "The Release Method". Removing Views from the DOM is all well and good ... but the Spine release method doesn't actually unbind model events that the view is listening to. Which makes it completely ineffective at fixing the memory leaks you're referring to. In fact, you can simply stop calling it (just remove the DOM element instead), and see that your app's memory profile remains identical. Unbinding model events you'll still have to do by hand.
7. "Routing Lives in the Controller". In Backbone, routing lives in the Router. Call it whatever you like ;)
8. "Model Adapters". Naturally, this paragraph would read pretty much the same if you replaced Spine with Backbone. Models are in memory, if you call `.save` they'll be persisted with the default REST-style Ajax calls, and there are plugins to make `.save` use LocalStorage, WebSockets, CouchDB, Mongo, etc.
9. "Get a Model from its HTML Element". Yes, by default Backbone doesn't use jQuery.data in order to attach references from the DOM back to models. Most of the entire point of using JS models and views is to stop tying your data concretely to the DOM ... so if you're relying on this feature, it's likely a place that's ripe for refactoring.
10. "Logging". No argument here. Backbone doesn't have any special logging over the built-in JS `console.log`.
Sorry for the exhaustive teardown, but there's enough FUD already. (And full disclosure: I work on Backbone.)