I think as long as "feature flag entitlements" are seen as distinctly different from what engineers usually use feature flags for (small incremental changes of individual components, testing, roll-outs, A/B testing) they can work well. An entitlement should have a clear link to a customer-facing feature, which are conceptually much larger blocks of functionality. One difficulty with this approach is that you still have to take into account a lot of billing-related aspects, e.g., handling customers in arrears, overage charges if they go over a certain limit, having different pricing models for the same feature, or resetting/carrying over usage counters on plan changes/upgrades - this can add a lot of complexity over time!
That's why we decided to offer separate feature entitlements that are tightly coupled to the billing chain and metering as part of Wingback (disclaimer: I'm the CTO). In the end, depending on your plan complexity and how much you have already invested in feature flags, I think both approaches can work well. Having some kind of feature gating in place for your customers will also make your life a lot easier for provisioning customer accounts and being able to offer custom packages.
That's why we decided to offer separate feature entitlements that are tightly coupled to the billing chain and metering as part of Wingback (disclaimer: I'm the CTO). In the end, depending on your plan complexity and how much you have already invested in feature flags, I think both approaches can work well. Having some kind of feature gating in place for your customers will also make your life a lot easier for provisioning customer accounts and being able to offer custom packages.