As you correctly determined, in a multiple release scenario, each new release would be a new branch (or set of branches) from the MAIN branch.
In TFS, Labels are NOT immutable, so it is possible that you label your code, release it, and then modify the label (to perhaps include a bug fix). In this scenario, the code in the label would NOT be the same as the code you released.
For this reason, our branching guidance suggests making a read-only branch with the code you release. This would allow you to get back to the release whenever you need to.
In general, we recommend against doing a forward integration (from MAIN to an existing release branch). In the scenario you mention: you don't need prior releases, and you are doing the Forward Integration at release time, I suppose you end up with the same
thing as if you had created a new release branch for the next release (and then deleted the existing release branch for the prior release).
Our recommendation against doing a forward integration is based on the assumption that you want to keep the prior release branch, and that you do not want to bring forward changes from the next release into a branch for a prior release.
As long as you understand the concerns, you could probably choose either option (new branch or FI from Main at release time).
VS ALM Ranger