Because feature flags often intersect with segmentation and AB testing.

So it's not just a byte in memory, but often also correlating the status of said byte with a users identity and then tracking and summarising user behaviour based on that relationship.

It's become fairly standardised and requires engineer time to setup and maintain the services behind all that, so it's valid to go third party for less than the cost of said engineer time, if all you want is standard.

Edit:it's also hard to always predict when a standard flags going to become part of a test, so just integrating for every flag and making that a standard process for your teams becomes the simplest approach.

I am not a fan nor a user of backend feature flags, so don't ding me for relaying this: they tout features such as central management of these settings, bringing them in the hands of the product team rather than being tugged away in code, allowing for canary deployments where you fade in a feature based on performance metrics, a/b testing, and so on. In their own interest, these folks take an as broad as possible view on what is a feature flag, often including things that you'd otherwise call system configuration or entitlements or permission toggles. It's not a new trend, LaunchDarkly is probably the best known commercial party here, and they've been around for about ten years, and I don't think they were first.

I wouldn't say a new trend, it did go through a hype cycle a few years ago, and some teams have adopted it. I definitely wouldn't call it a standard practice though, as it brings with its own overhead. In effect you've got "byte in memory as a service" with its own deployment, maintenance, and statefulness. It's only useful if you have a business model that really relies on having this capability. That could be in a sufficiently large, already complex, sprawling application estate, having a single flag in a central location could be useful if several pieces of your sprawling estate need it.