So if I'm understanding correctly, this terribly written article (he tries to make a point about merging but doesn't actually make it amongst other points he fails to even state) suggests using feature branches inside the code instead of feature branches within source control. It also requires mini code reviews and merging at every single commit. You cannot get rid of merging. Instead of doing it once when merging a branch, however, you're now doing it every commit. Since you're merging smaller chunks, it's impossible to see the bigger picture of the whole feature as you merge/review, and it removes the ability to do meaningful code reviews on features before they actually get into the main code base. Not only that, sometimes you end up in a race with your teammates, knowing that you're working on the same piece of code and that whomever checks it in last will have to merge. Stupid, but it can happen.

To me, the ability to have logical separation of the features being built and do meaningful code reviews far outweighs any proposed speed benefits of not branching, benefits that I assume show up only in larger groups as they certainly don't show up in small groups. Which bring me to my last point, the "slow is fast" section, which doesn't provide any evidence that slow is fast. Other than users not having to decide which branch to run (which takes all of two seconds, BTW), development is much faster with feature branches and the other negatives do not show up in my experience. What I'm trying to say is that "fast is fast." Slow is not fast and the author doesn't make his point there either.

tl;dr: All in all, he points to no actual pros to branch-less development.