The PR is optional, but governance often requires documented peer approval for all production changes.
Flag changes can be pushed directly to the main branch with the correct repo permissions. When using the GitHub UI this involves just a little bit of typing and a few clicks.
>might as well just change the code at that point
If changing the code, running tests, building, and deploying is quicker and less risky then yes that makes more sense.
This seems like a reach. A nice benefit of having these server-owned configuration flags with a slick UI (like launchdarkly) is that they can be modified by people on the fly, and by people who may not even be engineers (like product managers). I imagine, that if the ask is that they instead get GitHub permissions, make a PR, wait for a review, etc, then perhaps you are not competing with launchdarkly. Though, having Git controlled server-owned configuration is still nice regardless.
The sole reason I like feature flags is that I can quickly toggle off a change if it causes a problem. I'd hate to need to find someone to sign off on restoring service. Anything more than 1 or 2 clicks is just adding precious seconds to an outage. I've worked at places that gave broad implicit approval to developers to toggle away as needed. It worked well.
Flag changes can be pushed directly to the main branch with the correct repo permissions. When using the GitHub UI this involves just a little bit of typing and a few clicks.
>might as well just change the code at that point
If changing the code, running tests, building, and deploying is quicker and less risky then yes that makes more sense.