This is dead on, however I say it's a client code implementation detail that the object the view is bound to is the same one other parts of the app are bound to. Two way bindings about marshalling data out of the dom into JS land, and unfortunately developers seem to pick the wrong JS land object to store the view data in: the model. The model is best viewed as the client's best understanding of what is on the server: the canonical state of the modeled object in the world. Changing the value of inputs doesn't change the state of the object in the world until you press the save button. You do still want a canonical place for view bindings to bind to, so that different views of the same object are guaranteed to stay in sync (think the slug in an index as well as the detail view in a show action), and I say its not worth sacrificing this guarantee because we can't structure our code around binding to non-canonical representations. This suggests the edit views should be bound to something which knows how to apply itself to the model, so that upon saving, the canonical place can remain as such and updates with the new data.
In Batman we really want to make this other object a reality and have been scheming about "draft" versions of models for quite a while, but still haven't quite nailed down how to do it when things like associated objects enter into the mix.
> Changing the value of inputs doesn't change the state of the object in the world until you press the save button
This is key. If the UI is linked, checkbox by checkbox, field by field, to the model, then we've created the brittle situation where the user is, in effect, directly manipulating the "business objects". Such a scheme ends up imposing (at least) implicit design constraints when modeling the app (steering the developer away from the best or most logical decisions when they would make the rigidly linked view layer unwieldy), and similarly shackling the UX design to the model setup. Which makes for a worse app. These should be related but separate concerns; a smart user experience will require some logic, marshalling, and abstraction.
In Batman we really want to make this other object a reality and have been scheming about "draft" versions of models for quite a while, but still haven't quite nailed down how to do it when things like associated objects enter into the mix.