I found that most project using state labels have some kind of automation in place to make sure they are up-to-date (usually a GitHub bot or a GitHub action) or an active triage team. I think especially for state labels it is important to have clear guidelines and an entity that enforces those to prevent the labeling to get outdated and become useless.

I perceive adjusting labels after an issue is resolved as similarly error-prone as deleting a feature branch after the patch is merged. I usually do it, yet I have 50+ stale feature branches in several of my most active forks.

Since building an active triage team seems like a lot to ask from the volunteers here, I would prefer some automation. A not label-based automation are project boards, the nice thing is that they can change the state automatically on events like, closing or merging. I never been a fan of project boards so far for tracking releases (milestone labels work just better), but the workflow states might be legitimate application of those (see https://github.com/fortran-lang/stdlib/projects/1).

The good thing about project boards is that they disappear from the issue history completely once they are deleted, so if it doesn't work out, we can get rid of it again without a trace.