Unit testing will also force to decouple your code in a similar way. In the first example it is impossible test individually test all the things the code should do without worrying about everything else that is going on (e.g. you need make sure all the elements exist on the page). By moving to an event trigger like you suggest, you can then test that each listener does the correct thing independently of the others. You can have a separate test for 'selector' and 'yet-another-selector' and they don't need to know about each other. As an added benefit you don't need to mock out your ajax call either. Instead you can just fire a "DataModel:update" event in the unit test.
I've only recently grokked this aspect of unit testing and I feel like it's made my code an order of magnitude better and more maintainable. Thinking first about how to write code in a decoupled manner also makes unit testing really easy. After having tried unsuccessfully for years to test my code it was a revelation when I that it was because my code was bad that it was hard to test, not that testing is itself hard.
I've been using TDD for server-side code for some time now, but I struggled with it for javascript; I thought unit testing javascript was a myth. It was only when I started using backbone that I realised that I was writing horrible, terrible code.
I've only recently grokked this aspect of unit testing and I feel like it's made my code an order of magnitude better and more maintainable. Thinking first about how to write code in a decoupled manner also makes unit testing really easy. After having tried unsuccessfully for years to test my code it was a revelation when I that it was because my code was bad that it was hard to test, not that testing is itself hard.
Edit: I've tried to illustrate my thoughts more clearly with a copy-cat post to show the parallels between the two: http://news.ycombinator.com/item?id=4427842