Adding benefits of feature flags section

- On the feature flags process page there were a lot of examples of the
  cost of feature flags, but it the reasons we want to use feature flags
were not clearly spelt out. This change adds a section about the
benefits of using development type feature flags.

doc/development/feature_flags/process.md

@@ -148,3 +148,30 @@ they speed up the process as managing incidents now becomes _much_ easier. Once
 continuous deployments are easier to perform, the time to iterate on a feature
 is reduced even further, as you no longer need to wait weeks before your changes
 are available on GitLab.com.
+
+### The benefits of feature flags
+
+It may seem like feature flags are configuration, which goes against our [convention-over-configuration](https://about.gitlab.com/handbook/product/product-principles/#convention-over-configuration)
+principle. However, configuration is by definition something that is user-manageable.
+Feature flags are not intended to be user-editable. Instead, they are intended as a tool for Engineers
+and Site Reliability Engineers to use to de-risk their changes. Feature flags are the shim that gets us
+to Continuous Delivery with our mono repo and without having to deploy the entire codebase on every change. 
+Feature flags are created to ensure that we can safely rollout our work on our terms.
+If we use Feature Flags as a configuration, we are doing it wrong and are indeed in violation of our
+principles. If something needs to be configured, we should intentionally make it configuration from the
+first moment.
+
+Some of the benefits of using development-type feature flags are:
+
+1. It enables Continuous Delivery for GitLab.com.
+1. It significantly reduces Mean-Time-To-Recovery.
+1. It helps engineers to monitor and reduce the impact of their changes gradually, at any scale,
+   allowing us to be more metrics-driven and execute good DevOps practices, [shifting some responsibility "left"](https://devops.com/why-its-time-for-site-reliability-engineering-to-shift-left/).
+1. Controlled feature rollout timing: without feature flags, we would need to wait until a specific
+   deployment was complete (which at GitLab could be at any time).
+1. Increased psychological safety: when a feature flag is used, an engineer has the confidence that if anything goes wrong they can quickly disable the code and minimize the impact of a change that might be risky.
+1. Improved throughput: when a change is less risky because a flag exists, theoretical tests about
+   scalability can potentially become unnecessary or less important. This allows an engineer to
+   potentially test a feature on a small project, monitor the impact, and proceed. The alternative might
+   be to build complex benchmarks locally, or on staging, or on another GitLab deployment, which has an
+   outsized impact on the time it can take to build and release a feature.