That is only one use case for two-way data binding. A better example is that choosing an option in a select list instantly modifies your model, which triggers changes in some other computed properties on your model, which instantly binds back to the UI to populate that second drop down list with the filtered options.

If you think it's oversold, you've probably only seen a bunch of stupid tutorials about neat features with it.

What Two-way data-binding gives you is a structurally-controlled presentation layer.

You can represent the page's state as objects with properties, and it "just renders". You can have a "readonly" property, and it makes everything readonly. You can have a "show edit box" property...bang. A "loading" variable, etc.

The idea is that you can treat the front end html like everyone else has always treated their world: as a finite state machine.

Since I am primarily a back-end developer (with more middle-tier experience than I originally would've wanted to admit), this jives really well to me. Instead of jumping in and hacking at the DOM every time data gets updated, I just use Angular for pages that are "that dynamic".

I really don't want to have to render new DOM elements (even with a template engine like Dustjs) and overwrite them into the page, just to represent a small state change.

With a data binding library, I don't have to. I don't use Angular for many things, and I sure don't use the "SPA routing" functionality... but when I need to do constant rapid-fire AJAX requests for growing subsets of a huge dataset (say, schools/programs by region and proximity), Angularjs saves you a lot of code: code that's generally quite ugly.

The two way binding can be so useful though. The best example I've seen was an array of coordinates bound to a directive that used D3.js to visualise it. There were some special function you could call that would affect and expand your data and immediately update the graph, and you could manipulate the individual points on the graph and it would propagate to the data seamlessly.

I guess to me two way binding is one of those things that you don't think of often, but when you don't have it you suddenly find yourself writing tons of boilerplate code to get the same effects.

The only cases when I didn't want the two way binding were when I was creating or editing an item. And then it's trivial to bind the form to a separate object while you work on it, then push your changes to the collection/original when you're done.