A temporary feature flag is very good at becoming a permanent piece of the application. It starts as a way to control a release, then hangs around because removing it feels less urgent than the next change. Eventually nobody is quite sure which branch still matters or whether the old behaviour is safe to delete.
Pete Hodgson’s feature-toggle guide makes a useful distinction between different kinds of flags and their expected lifetimes. A release flag and a long-lived permission decision solve different problems. I would avoid treating them as interchangeable just because both happen to be a boolean in the code.
If a release needs a flag, give it an owner and a removal condition when it is introduced. Decide what evidence will make the new path the normal path, then include the cleanup in the work. Also check what happens when the flag’s configuration is unavailable. A control intended to make a release safer should not leave the application with an unexplained default.
Some features need staged exposure or a quick operational switch. Others can be released through the ordinary deployment process. Choose the control for a concrete reason, then retire it when that reason disappears. Leaving every alternative available forever is a fairly expensive way to avoid making a final decision.