Trunk Based Development vs Successful-git-branching-model

At work I've faced 2 generic approaches to branching:

1. "Modern", where we have branch-per-feature policy:
   http://nvie.com/posts/a-successful-git-branching-model/
2. "Classic", where everybody commit to the trunk and branches are made only for releases:
   http://paulhammant.com/2013/04/05/what-is-trunk-based-development/
   

Both approaches are very interesting, but my personal favorite is "Classic" one. Because:

1. CI  (Continious integration)- you merge often, and you have ci server testing your code. In first approach, you'll need job-per-branch, and there are a lot of them! In second, one job will notify you then your commit is breaking something
2. If your changes are not compiling\not all test pass? Well, in this case solution is to commit but don't push.
3. Second approach forces some sporadic code review, when 2 developers change some linked source - and this triggers communication and is a good way to common vision.