...which still begs the question - why does it need to be an entirely different service?
Probably answering my own question, but the main reason I can think of would be if your app doesn't have some kind of business admin panel capability.
I suppose my bias is also that in my sphere of web dev, we build these business panels pretty frequently, so feature flags and a UI for toggling them is something that makes sense to do within the app rather than add a third party service (and associated cost + potential latency) for it.
You mean an admin panel on a server application, right? At my current job, I'm on a platform team that supports hundreds of applications. Each of them have their own admin panels.
However, there are settings that apply to all of them in our library code. For those, we use feature flags, and they are loaded from a network service, environment variables, code and config files. The overriding logic is complicated for legacy reasons and prone to bugs, so we are moving to a centralized feature flag system.
Fair, that makes sense. Not a very common use case I think unless you're talking more about heavy use of microservices that need a feature flag across the entire suite.