I put this in another comment, but disconnecting of code and feature release can still be achieved while storing feature flags as code. You need to build out a seperate pipeline and release process. With this you can still achieve all the advantages that you listed out.
I think the key difference is if you consider feature flags to be configuration and believe in configuration as code as a best practice.
I think this is the right approach in the long term. People having the ability to modify configuration in production in real time is an outage waiting to happen without having an obvious way to rollback to previously known working state.
We certainly see workflows where defining everything as code can be powerful. As we've been chatting about this internally today, we have ideas of how you could define all your features / audiences / variables as code and only deploy changes using a Terraform interface.
I feel like, ultimately, this overly limits the reach of feature flags within an organization; it makes it more difficult for most engineers who are not comfortable with Terraform to deploy their features; it limits the ability of product / marketing / project managers / QA from; scheduling releases, configuring experiments, testing features, modifying audiences, etc.
Modifying configurations certainly can cause production issues, which is why we have built tools like our variable schemas and strong typings for our variables to limit the value changes to only known values. With our CI / CLI / IDE integrations, we make it known what values variables can be set to, when variables are added and removed, and when variables enabled in production are modified by PRs. This is all in addition to existing permissions / change logs / rollback functionality we are improving on. One of our core responsibilities is to make changing Feature Flag values as safe as possible. We know that flags can quickly become tech debt, so we also preach that feature flags should be as easy to remove from your code as they are to add to your code.
A fully featured feature management platform should be with you from your IDE / CLI, Code Review / CI, Deployment Pipelines / Alerting and Monitoring, and integrated with your Project Management and Product Analytics. It should be visible to your team throughout their workflows what features are enabled across all your environments.
I think the key difference is if you consider feature flags to be configuration and believe in configuration as code as a best practice.
I think this is the right approach in the long term. People having the ability to modify configuration in production in real time is an outage waiting to happen without having an obvious way to rollback to previously known working state.