Each branch has its role - its purpose. Its entire reason for being. Once that purpose is complete, the branch should be closed for further changes and merged back into the mainline.
Having a perpetual release branch means that the purpose of the branch is never complete, as it is perpetually open for changes. Each time you have a new release, you find yourself merging from the development branch into the release branch. And this isn't a merge of ideas - it is a complete replacement of the state of the release branch with the current head of development efforts. When it isn't a complete replacement of the state of the code from development (which is in theory, ready for release), it provides a place for bugs to creep in that differs between the release branch and the development branch.
That complete replacement of the state rather than a merge is a distinct hint that the old branch is done and this is a new one. To make that clear to everyone, here is a different release branch.
Consider also the (not unlikely) situation where there are two releases on going at the same time. The release effort takes two months to do (certification, testing, more testing, fixing bugs that show up in that release effort, recertification, packaging for the different builds). And now, one month in, another release effort starts for the next release. This is a different purpose - a different branch.
Or consider the situation where you have a release branch, which you then branch for each platform that you are going to deploy (making the tweaks to get it to work nicely on Mac, Windows, and Unix systems). And while release 1.0 may be out the door for Windows, the Mac and Linux efforts will take another chunk of time(while you are readying the 1.1 release). Again, each of these is a separate release and a separate branch.
One of my favorite whitepapers on branching is that of Advanced SCM Branching Strategies. While this has a focus on perforce (a centralized version control system at the time). The concepts that it puts forward can be clearly mapped into the git-flow model.
In this whitepaper, the packaging role is the one that maps to the git-flow release branch.
The packaging role is often confused with the accumulation or, more commonly, mainline roles. Once the intended development and maintenance have been performed and any accumulation has been done, it is time to prepare the code for release. Such an effort may not be trivial, requiring a team of release engineers and additional fixes beyond those already performed. The policy on a packaging branch is significantly different from that on a maintenance branch, as the packaging role suggests, only the changes necessary to make the product releasable should be addressed.
If work is to proceed on the other product branches, as is likely to happen if patch levels of the product are to be produced, one does not want the release effort to stall progress toward the next patch level. Other packaging branching strategies could even keep minor versions running off of the same mainline, compounding the potential for a stall while the packaging activity takes place.
Using a separate branch to insulate the release effort from the ongoing development and maintenance, and vice versa, is recommended. In a multi-platform environment, it may be advisable to create one packaging branch per platform for the final porting effort. If the porting efforts are staggered, this allows the staggered releases to be reflected in the version hierarchy. If the porting efforts are simultaneous, accumulating the per-platform packagings to a master packaging branch, from which the final build would be performed, should also be considered. This should be determined in advance, as creating the separate packaging branches from the master packaging branch works best.
This is why you separate the release branch from the mainline branch, and also why you separate the release branches from each other.
