Well, first, one of the points of branches is "don't break the build" since you always know that master is an appropriately tested version of the code. Branches give you feature isolation.

Suppose that while developing a feature, you realize that a piece of code is buggy. In your view of the world, where everything is linear, either you drop everything you're doing and fix that bug, or file a bug with the tracker, deferring it until someone has time to fix it.

But morally, the second one is just a branch--time in this case isn't linear. You (or someone else) will have to change contexts at some point and fix the bug. If it's after your feature has been committed, then you have to do it on code which may have churned quite a bit since you filed the bug.

So if you used branches, you would just create branch for the fix. If it gets committed into master before your feature, you could obtain upstream changes. If it gets committed after your feature, you can use rebasing to replay that work on top of the significantly changed code.

If you need to do big arch changes, you still do them in bits such that every build isn't broken. You just do them in a branch, so that nobody else sees them until they are completely ready.

Note also that, with git's powerful tools, you have the option (which is usually taken, these days) to rebase your branches into master, not merge them. So, when you published your changes to the world (git branches are local, nobody else can see them) you could still show the world a linear line of development if you so pleased.

So it may not be a "this is better than this" mentality, but you definitely do lose a significant amount of expressiveness and flexibility for no reason. Branches are painless (in git) and certainly not a waste of time (in that they actually streamline the development process). Can you describe the situation in which you thought that was the case?