I would strongly recommend that you run a controlled comparative trial to find out which way is better for your project instead of wasting efforts and ruining team communication on fruitless "theoretical" debates.
In one of my past projects we wasted time like that for more than a year until we decided to do such a trial run. First, we run it for a few months, carefully tracking time spent on branching made the "established" way. Then, we spent few months running and tracking "alternative" approach.
After completion of our comparison, we simply studied results of tracking and have chosen the way that looked less effort consuming (if memory serves, we had about
4 hours a week average per developer using one way versus
0.5 for another way). No debates, no hurt feelings, just business. People get objective numbers, compare and make informed decision, it is that simple.
This will prove difficult... I can't imagine an objective way to reconcile this.
Well in our case it wasn't really difficult. It likely looks difficult the same way as it is difficult to debate branching approaches differences "theoretically". When running the real trial, all this broad stuff magically gets split into small, concrete, manageable use cases that are much much easier to evaluate.
Things worth keeping in mind is that 1) few months mentioned above were proven sufficient to carefully evaluate efforts supposed to be related to one or other approach and 2) while trial is running, it is most important to just carefully write down stuff, leaving discussions on it to be dealt with separately. It was like,
- "spent one hour integrating with half-baked component change committed by John"
goes to ticket labeled
- "spent one hour investigating the bug introduced in recent branch merge from Paul"
goes to ticket labeled
At the end of the trial, this data is "extracted" from issue tracker, discussed and clarified. Results are exported to Excel, difference is calculated and preference is made based on that.
It is really important here that teammates record anything that looks like maybe related, because if not recorded, data that is maybe important is lost. As opposed to that, for the data that is recorded, it's not difficult to drop out the stuff that deemed irrelevant in a more thorough discussion at retrospective analysis.
- ...And yes, in our trial we dropped some records that way, ...and no, there was no heated debate there, because 1) this was all about discussing real, concrete use cases, practical and material up to point of feeling quite strategy agnostic. And because 2) the team was interested in finding the way that saves our efforts for more interesting stuff rather than in religious debates on whether to branch or not to branch.
This somewhat resembles a Postel's law (aka robustness principle),
be conservative in what you do, be liberal in what you accept from others
As for situations where Branching is a bad idea, well when preparing trial run mentioned above we studied available information (summarized in another answer at Programmers) - just to find out if maybe we can avoid spending few months on running the comparative trials.
From what we learned back then, the answer is "it depends on the project":
there's no commonly agreed "best" branching strategy applicable to any project
most resources seem to agree that choosing productive strategy depends on the particular project specifics
side note. Based on above it looks like any changes to project branching strategy need to be tested, measured and compared to other options tested...