To me, branching by feature only makes sense when you have a large enough project that you can speak intelligently about the "X feature team" as an independent unit.
Moreover, there are certain size criteria (admittedly fuzzy). If you have 10 developers, you only have 1 feature team as far as I'm concerned -- doesn't matter if two of them are always "the widget dialog guys" or "the database guys." You may very well need >1 development branch if someone is doing a major refactor, making a breaking change to APIs, altering expected behavior such that many BVTs will fail, etc. But that's not a feature branch.
If you have 100 developers, you may need feature branches. It depends how tightly coupled your features are and how disciplined your SCM process is in general, especially with regard to build quality. Even if you don't have feature branches, you'll certainly have some sort of branch hierarchy.
If you're working on Windows, layers & layers of feature branches are a godsend. If the shell team can't be productive because the kernel team introduced a bug, that's a frickin' big problem.
Of course, there's a balancing act to be made. Some large organizations take feature branching too far. When it starts to take months before code blessed by feature team X makes it up to team Y, the pain of merging + integration testing will outweigh the codebase stability you tried to gain in the first place. (hence the phrase "your tree's depth from MAIN is inversely proportional to your sanity") And in every case, the tree for version N must narrow as its release approaches, eventually collapsing to a point where only checkins directly to that release's trunk will be included and every feature branch is effectively targeting N+1.