why would you need to recreate the whole branch when a
new feature is ready?
The reason for doing this is to ensure that the QA branch is
completely up-to-date. Suppose there had been a hotfix since the last
time it was recreated - recreating QA from scratch ensures it starts
out with the latest code from master. It's also entirely possible that
developers have pushed minor changes to their feature branches in the
meantime (even if they're not supposed to) so this ensures the latest
commits from those branches get pulled in as well.
I think the simplified version you mention could definitely work,
especially if the project is not doing any continuous integration. It
would mean that merging a feature into QA is potentially much more
difficult because each commit could have conflicts needing to be
resolved. But if the "features" are more like bugfixes as you say,
they are probably only one or two commits anyway so this doesn't
matter so much.
why would you need to
The reason for doing this is to ensure that the QA branch is completely up-to-date. Suppose there had been a hotfix since the last time it was recreated - recreating QA from scratch ensures it starts out with the latest code from master. It's also entirely possible that developers have pushed minor changes to their feature branches in the meantime (even if they're not supposed to) so this ensures the latest commits from those branches get pulled in as well.
I think the simplified version you mention could definitely work, especially if the project is not doing any continuous integration. It would mean that merging a feature into QA is potentially much more difficult because each commit could have conflicts needing to be resolved. But if the "features" are more like bugfixes as you say, they are probably only one or two commits anyway so this doesn't matter so much.