Actually it does. In a branch model, new content is being created independent of the main line. Bug fixes on the other hand are implemented on the mainline as well as the branch.
What this means is that bug fixes can be rolled out simply through the QA process, while new features require substantial patch releases and testing cycles because it isn't merely a fix to mainline but an entirely different branch.
This is why they sometimes mention that they would like to release things sooner but cannot because of the work involved in breaking out one new feature from the branch, and merging it back into the mainline.
Releases that are designed around regular patches typically have this kind of structure.
You have a mainline (2.0) and a development (2.1) which is where major changes go into. You maintain 2.0 for bugfixes, but only occasionally backport changes from the development line (2.1) because the differences can be substantial in the code base, making it very difficult to safely do. Usually backports only occur for substantial flaws like security patches, where the current design is fundamentally flawed.
Once 2.1 is rolled out, they branch again (2.2) where again major changes will be going, and the process will continue. 2.1 will be hardened and only changed for bug-fixes or minor changes which are implemented simultaneously, or very rarely a backport.
Trying to implement substantial changes into both branches would require a significantly more aggressive QA progress and instead of speeding up patches, would slow them down. (or would involve releasing less tested software... Which nobody wants)