This is where I got the idea,

http://fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.wiki

Please see the Table on the top and the 'Branches' section.

Ok. I think that is a relatively accurate description of some normal git processes, but I don't think that's saying what you're getting from it.

You may be taking too strong a meaning of the 'ownership' concepts described there (and I think they're stated too strongly). No one owns a branch name in git, not even the person who first makes it. You own the branches in your own local repository, and you can choose how and if you share them, but it is perfectly possible to do shared work on a branch if you have a shared repo to work from (and even, with some extra work, without one).

This is basically a Zooko's triangle[1] problem, where git has chosen decentralized and meaningful, which necessarily implies a rejection of ownership (even to the extent that Fossil wiki page implies).

But in the end, most branches in git are focused on a piece of work and not who made them (it's mostly the 'lieutenants' in the linux model who would have personal branches). Single-author branches may be more common in git because it definitely does make those easier than other possibilities, but there is nothing stopping collaboration on a shared branch in git.

[1] http://en.wikipedia.org/wiki/Zooko%27s_triangle

It's probably pervasive because of github and pull requests where, at least for open-source projects and external contributors, it's true in practice though not enforced.

I'm confused as to what "it" means here?

If you mean the idea in the GGP's post that branches represent a user's work, again I think that conflates repositories with branches. It's not exactly impossible to find people doing work on master of their fork against an OSS project, but best practices (and common practice among most regular contributors I've seen) seem to angle towards using feature branches even then (and asking with a PR to merge eg. stormbrew/blah:fix-the-thing to upstream/blah:master).

Even in that case, you're talking about a clone of the repository, not a "user's branch." That would be the "user's repository", which has branches corresponding to features, and bugfixes (unless they are a user on Github who isn't too familiar with Git, in which case they'll just commit to their "master" branch probably). If each user has their own fork, as is typical on Github, then it makes even less sense to have a "user" branch.