Not only does working on a branch sequester each developer's individual insanities until merge time, it lets other team members keep an eye on that branch so there aren't big surprises when merge time comes around. We want both aspects, not just one or the other.

Back in the early days of computing, a programming team was likely to share a single expensive computer.

Then we had the PC revolution, so each developer could have his own computer, but we kept those devs in cube farms or similar shared working spaces, and they had a LAN to coordinate their work.

Then the Internet happened, and we started doing distributed development, so we invented Subversion and mailing lists and suchlike to give team members a way to coordinate their efforts.

Then we got DVCSes, which have their uses, but they cause a new problem, which is that they let developers fork the project and go off on a tangent, completely unmonitored. When they pop up weeks or months later with a new feature, that feature may not even merge cleanly, or if it does, it may not align with the core developers' vision of where the project is going. So, the fork is never healed, and you end up with a choice of forks, no better than old-style project forks, where the dissenters just copied the project repo.

This problem was solved in the Git world by Github, which effectively turns forks into a special kind of branch, in that you can trace forks from parent repos to children, and merge child forks back in just as easily as internal branches.

Fossil solves it differently by strongly encouraging a central-and-clones model: it helps maintain team cohesion in a distributed development environment. Fossil actively fights against users going off on a tangent. This is a good thing.

You can force Fossil to work like stock Git, but its default configuration fights against that, on purpose.