The problem comes when two people are developing stuff in two branches that conflicts. When the first merges in, the second now faces the huge painful merge.
Well, yeah. But that's not because of technology choice or development methodology, it's because simultaneous work by two developers on the same lines of code is fundamentally a really hard problem. It was hard before source control, it was hard with SCCS and RCS, and it's hard with git.
No matter which way you slice it, one of the two developers (maybe both) needs to sit down and figure out what the others' changes do and how they interact with his/her own. That's a wetware problem, not something you can fix with a tool.
That's true. But if both developers are developing out of the same branch, and are checking in small patches at a time, they are more likely to notice the interaction as it is happening and actually talk to each other.
The more difficult problems come when each worked on it for 2 weeks, then they discover a month or two later that there is a conflict - after both have forgotten what they were doing and why they were doing it.
By the time you've noticed that it happened, it is too late to avoid trouble.
Furthermore many organizations set up and organize branching in such a way that you have no option to freely define your branch like that. For example in the Microsoft story I linked to there is a multi-level merge process. If you just merge from a random other branch, then multiple merges later when code from your branch is officially merged with the other branch you'll have caused a nightmare because you've got an old and buggy copy of all of the changes in that other branch. The people whose job it is to sort it out will want to kill you. Particularly if you've merged in code that was explicitly discarded from the other branch.
The problem comes when two people are developing stuff in two branches that conflicts. When the first merges in, the second now faces the huge painful merge.