The simple labeling approach can certainly work in some cases. Yours may be one of those. But it is very simple. There are some pitfalls to assess. Here are two.
First, if you read some of the other posts, you will see people caution you that labeling is not good if you need an authoritative snapshot since labels can be modified. If that concerns you, consider their advice.
Second, one thing to watch with this simplified model is where you deploy your release from. Up until the time the new release is in production, you will want to reserve the right to make changes to the previous release because it is live. What
you would NOT want to do is merge from dev to main, then to the release branch, then undertake a multi-week testing protocol with the new release in your release branch and no way to do hotfixes on the old release. That would be the wrong way to use
the model. Instead, you would want to stabilize the new product and get it acceptance-tested and deployed from another branch (like Main). Then you could promote it (merge it) to the release branch at the time it is deployed.
These two nuisances are just some of the reasons why some of us just make a separate release branch for each release. It's clean, it's simple, and it avoids lots of problems. The only reason I can imagine for NOT having separate branches would
be if your source code is HUGE and you cannot afford the storage space of multiple releases, and you have lots of releases.
But you certainly can use a shared release branch if you are aware of its limitations and they do not apply.