In my experience the “off” path is only well tested the day the feature is released. Once the feature is out in the world the old tests go stale, and manual tes

In my experience the “off” path is only well tested the day the feature is released. Once the feature is out in the world the old tests go stale, and manual testing in effect never happens. It gets worse when a new ungated feature is built on top of something that was behind a flag (but always set to on). Suddenly code that was expected to always run doesn’t, and all kind of expectations get broken. I’m most concerned about “What happens when your flag manager fails to return data.” This should be a rare event. In my previous organization (~500 devs) it happened twice, and was catastrophic for the ~4 hours to get everything fixed. If instead some unpolished features had leaked for four hours, no one would have cared. If your organization has excellent hygiene at cleaning up flags, then off may be the sensible default, since you won’t have 10 years of cruft blowing up at once. But building a culture with that kind of discipline is hard, and automating it is non-trivial/often difficult to get developer resources for. Defaulting to “on” can be a pragmatic choice when you can’t invest in paying off all the tech debt.