This sounds like it could easily and quickly lead to really poor bug reproducibility, documentation, and discovery especially if the issue is in action-at-a-distance anti-patterns. Am I just being a curmudgeon or is this a reality?

I'll happily accept a "no you're crazy".

For smaller projects and teams, something like feature flagging can probably be avoided unless A/B testing is required.

For a company that has hundreds of engineers, with daily continuous deployment, it helps to have certain in-development features gated behind flags. When it comes time to deploy these new features, they can gradually be rolled out to users. If the feature starts triggering exceptions, it's very easy to scale back.

Once the beta feature becomes stable, often the feature is removed (along with all logic in the source code guarding this feature).

Similarly, for A/B testing, the feature flagging and logic is removed once a test is deemed to have either passed or failed the A/B experiment.

Like anything else in software, feature flagging can incur technical debt if not properly maintained.

This is used extensively. X customer wants to test y feature, but z customer is the middle of a large test and refuses to see c feature.

Roll out feature to test client, slowly roll out feature to each client.

Something to wrong? It’s incredibly fast to update the flags.