I think this restriction is quite limiting to use the Discourse software in more advanced public project workflows, where you want to have more specific rules, but still to be open for the audience which is not educated about them.
Custom flags with proper descriptions and links to relevant help articles is currently the easiest way to communicate to the user the expectations and rules of the current forum. Unlike the separate docs with a large list of rules, the flag description is visible exactly when needed and to those who need it - both people who set the flag and to those who receive it. Flags is the Discourse super-power from what I am seeing.
For example, in our case we need to clarify to a user that some areas of the forum have much more strict definition of what constitutes as offtopic and generic off-topic flag is not good enough for it. (Basically every use of the system flag with Off-topic label currently triggers a reply - “but this is not an offtopic” and we have to have a personal conversation about why it is off-topic under this specific constraints.)
I would create the specific “Does not fit the workflow” flag with a proper description for that case and a link to the workflow documentation. I would iterate and tailor the messaging on the flag, as the description needs to evolve together with the evolution of the underlying workflow.
But because you don’t allow to edit it, I can not even fix a typo, not talking about more elaborate explanations even.
I understand the “don’t change the history” concern, but there are ways to workaround it: for example make only the description field editable; or add a new editable “doc/help” field; or add a new version field to the flag and bump it on edits, so it is visible that the post was flagged with previous version… etc
P.S. Does the limit on 50 flags count also the disabled flags? If yes, and I both can not delete disabled flags and can not edit them, then flags is a limited non-renewable resource which is not sustainable for any long-term setup.