Because not everyone wants to define application behavior in markup.
This just does not jive with me. My template knows that submission should be handled by `addTodo()`? Or even worse, looping. I want all of my logic to live in code, not some abstract framework specific attributes that don't add much in the way of clarity (context switching between template and view just to follow the workflow, for example).
I use (and love) Backbone because the DOM is considered a pure presentation layer, nothing else. Any behavior, logic, whatever that the code controls is defined only in the code.
You don't actually have to do it that way in angular if you don't want to. You can put it all in code instead. The framework specific attributes you're looking at aren't exactly framework specific, they're kinda application specific (just happens they ship with the framework).
You can write your own ones to move any of that stuff into code instead of markup. I personally think that loops should be in markup - I happen to prefer templating systems with less restrictions.
Most template engines support loops. Would be very weird without that capability, really.
Also, you have to add hooks to buttons and the like somehow. There isn't much of a difference between adding a class like "js-addWhatever" or using Angular's in-your-face approach.
Your template will also use names of properties, arrays, and objects directly. There also isn't a way around that.
At some point you have to connect your pieces. They can't float around in mid-air forever.
The presentational things you mentioned are different. We can separate those things more, we can use abstractions, and we can make it extremely reusable.
It doesn't matter if that identifier is a class or something else.
Well, if it's a class people may feel inclined to reuse that identifier on the CSS side, which is a bad thing, because now you've tied 3 parts together instead of just 2. If I use classes for this, I prefix them with "js-" to indicate that they are only meant for scripting purposes.
With a class "acceptButton" you are specifying what it is, semantically and declaratively, without reference to some specific procedure that will be carried out, if anything will be done at all. This frees up to a great degree the range of code that you can write to "activate" This html, and also, makes it so that the HTML is not bound to some specific code base, and it can be parsed in situations that explicitly ban javascript.