What he describes as bad about feature flags is exactly the reason I want them. In most cases, the timetable to put something online does not need to correlate with deployments or releases. So as a developer, I happily outsource that decision to the product manager, give them the ability to rollback a feature if it's not working and of course I'm giving them the capability to designate a testing group if the feature needs critical evaluation. Yes, managing feature flags is a pain, but they are essential for separating concerns between management and development.
It's good for another reason too: it decouples releases from deployments. Both deployments and releases are high-risk activities. Performing them together increases the risk multiplicatively.
Separating them does also create some incidental complexity (permutations of configurations, feature flag management) but in my experience that complexity is easier to analyse and deal with. (Dealing with feature flag complexity involves retiring them promptly, differentiating between feature flags and kill switches, etc.)
Of course, TFA knows this. They've moved the goalposts by making an extreme claim ("every" change behind a flag) and then argued against it.
