The advantage is that the controller knows nothing about the DOM, so it is usable and testable without the DOM. And while I agree that it's a single line to add a binding, that quickly becomes a single line for every single event you ever want to listen to. It ends up being a sizable amount of code. Aside from that, it seems clear that binding data is best done in the view, not in the model or controller, why are events different?
2) Using normal JavaScript objects
You don't have to extend the objects with Serenade.Properties. The downside is that data in the view isn't automatically updated. But as in the first examples in the README, it's perfectly acceptable to send in "JSON" directly to the view.
In the example right after the one you posted, I show how to add properties to the prototype. The intent is not to sidestep prototypal inheritance, but since multiple inheritance or mixins aren't available in JavaScript, copying over the functions is as close as we can get.
3) Break out
I just realized that it's not documented in the README, I'll have to fix that, but it's possible to add custom instructions. Any function added to `Serenade.Helpers` is available as an instruction in the view. This is very similar to handlebar's registerHelper. See the spec here: https://github.com/elabs/serenade.js/blob/master/spec/integr...
4) Performance
I have not done any benchmarks, so honestly I can't say how it compares performance wise. I'm not terribly worried about IE7. At the moment, we don't even support it, and it'll be dead soon. We could possible use document fragments to speed up the rendering, but I'm unsure if it actually makes a difference. I would argue that Rails is slow, Ruby is slow, PHP is slow, Java is slow, C is slow, etc..