Depends on how long the time is between commit and live-in-production, and on how severe the impact is. And also on the number of developers committing changes to the same codebase/app.

If it takes you >20 minutes from when you commit to when it's live in production, and an incident arises due to the change where data loss/corruption increases in "blast radius" more by having the breakage in production longer, then a feature flag might be a great way to give you an immediate "kill it" switch.

One possible alternative that could give an immediate "kill it" switch is to deploy the last-known-good build, but that only works IF other non-revertable changes haven't shipped since your change (like non-reversible schema migrations), and also IF your time-to-deploy-existing-build is sufficiently fast (it's pretty rare that you actually have instant deploys in live production apps).

If you're in the situation where you have multiple developers committing unrelated changes to the same codebase, and non-reversible changes are a possibility, and your CI/deployment time is sufficiently-long (>5minutes, maybe?), then yeah, feature flags are probably a better fit than "just revert the commit".

For one-man projects with a slow rate of change and a fast CI/CD pipeline, sure, feature flags are overkill.

That is a simplistic answer.

In a CD setup without feature flash, commit equals deploy equals launch. With feature flags, commit equals deploy. Launch is controlled by feature flags.

For a more mundane analogy, would you rather have a stove that allows cold or burning only, or one with every possible nuance of warm in between?

For websites, the value is that feature flags should be much faster than the revert/deploy cycle.

At $PRIOR_JOB, a revert/deploy or rollback takes tens of minutes of the main application.

Sure, though if your back-end has multiple services this becomes harder. If your back-end uses more than one server, then you can run into issues.

Feature flags also let you do partial rollouts, where you release to 0.1% of users and see if stuff breaks. Or A/B test to see if your feature improves whatever its meant to improve. It also lets you roll out the feature selectively to certain users if it's a breaking changes and each user needs time to migrate.

There are other uses if your flagging system is not "all or nothing". They can be very useful if they support directing a subset of users, customers, or traffic to new code/infra. The bigger a team gets, the more value you get from this.

In fact, FF like this can be used for A/B testing too.

Exactly.