"Just use a database table" solves for the simplest cases - a single monolithic app. It works incredibly well in this case. It falls apart when I need to turn features on across multiple apps together.
I think OPs point was a simple app doesn't need this whole suite of tools, but you pay for them anyway, which makes it a bad cost/value proposition for simple apps.
So yes a more complex situation could benefit from all this extra tooling and complexity but otherwise it is dead weight/cost.
I would claim that release a new feature by enabling additional code path across multiple apps at once is a bit of an anti-pattern. It seems rather dangerous and error prone. In that case I'd actually release it in reverse order, so to speak. Release the apps that use the services of others first and have it check is this service is available/functional and if not, skip calling it. The release the feature to the next service down the stack. Then you can always rollback the last service and be confident that the callers still work.
It's way more work and I can see why for certain types of application isn't not really worth the trouble.
> Just use a database table" solves for the simplest cases - a single monolithic app.
Most cases are the simplest cases.
No approach works for every single use case, but OP was specifically talking about the common case. You don’t have to shoot for the most complex use case every time.
So yes a more complex situation could benefit from all this extra tooling and complexity but otherwise it is dead weight/cost.