So you're essentially advocating testing new code, or new combinations of code changes, in production?
For a feature flag to be useful compared to the typical setup where you have a feature branch and then rebase that onto master from time to time until you're ready to do a fast-forward merge, you would need to be testing multiple features concurrently before any of them is merged back to master.
Testing all possible combinations of unmerged features in development is an exponentially difficult problem, so surely no-one is doing that. However, even testing selected combinations still requires someone to be aware of everything that is going on in enough technical detail to highlight potential trouble areas in time to take useful action that would become more difficult once some of those features start to get merged in.
Assuming you have a large enough project that co-ordinating different ongoing development work isn't just handled via informal discussions anyway, that would mean someone has to be identifying risky combinations that could benefit from testing in advance, and someone has to be responsible for doing that testing, and someone has to be responsible for addressing any issues that are discovered as a result. Does anyone here work in a development group that actually does this?
Meanwhile, the cost of using feature flags routinely is clear: every time you do any significant development work, you have to bracket all affected code with a new flag, and someone has to coordinate those flags and make sure they're all tidied up with code left in the "on" mode by release time.
The advantages of feature flags over feature branches are mostly an illusion, though.
Sure, if you're updating your code in co-ordination with updating some external system, such as a database migration, then sometimes deploying in stages with multiple versions of some functionality running concurrently during some of the intermediate stages is more-or-less the only way you can do it without incurring downtime.
But otherwise, even if you have 10 teams and each hides their changes behind a flag and pushes to master instead of a feature branch, you still have an exponentially growing number of combinations and they're still not all being tested in arbitrary combinations. Turning the feature flag on is then little different to merging in a feature branch: it's still a time when things can go wrong. It's just that now they're going wrong on your master branch and screwing things up for everyone else, too.