The key is the question of what the policy for Master is. With git, typically, the branch policy on Master is the
buildable stable release. Sometimes, Master is the 'mainline' where branches are made from and merged to prior to merging to a Release branch. These are two different role/policy approaches.
It is often a source of errors for people to change the role or the policy of a branch part way through the project. It is easier for a solo developer to communicate these changes out to contributors, but trying to get a dozen programmers to all recognize "Master is now at 1.0, please branch features rather than everyone pushing to it"
I touched on the policy approach above. The policy for Master is that it is the
buildable stable release. Checking in small incremental changes into this means you don't have something buildable stable at all times. Not checking in small changes goes against the "lots of small (but complete) checkins" that tends to be the best policy (and encouraged by easy branching).
From a role based perspective, you've started out with master being mainline, release, maintenance, and development roles, and then some point down the road the development and maintenance role moves to branches. This again means a change in what is allowed on master and can confuse contributors as to where things belong. It can also (slightly) confuse the branch history, encouraging large commits that mean bigger and harder to understand merges.
Key the roles and policies on the branches simple and consistent from the start.
This "branch on policy change" can be seen in the Branching Patterns. The idea of each branch having roles, can be read in Advanced SCM Branching Strategies. Both of these are very good reads.