One nit from the essay: the author comments on the missing 'model' from Angular and provides an example of a computed property to illustrate this. In many (not all) Angular applications, the server is responsible for the model (think a Parse or other REST-style backend), and the Angular app is simply responsible for rendering it. Angular (err Restangular to be specific) has a way to do this with less code and an aesthetic (data binding in HTML) that I personally like. If, however, you were writing code that needed the client to have a lot more business logic (i.e. computed properties, browser local storage, etc) then something like Ember would be a better choice because of its 'Model.' A lot of shit crud apps, however, don't need that much business logic in the client (at least for an MVP), and that would be my narrative for why Angular appears more popular. That said, I use computed properties in a couple places with Angular, and watches have performed perfectly fine for my use (gallery of 1000s thumbnails). He should disclaim that YMMV.
Neither is inherently better, and both teams working on them are full of smart, quality engineers that understand these problems in ways I never will.