I think it's a matter of unknown future needs that's the problem. If you want to do feature flags, you can basically build a service that stores key value pairs segemented however you please, throw it behind redis cache, and call it a day. This is faster and probably cheaper than buying a SaaS!
However, if you want a bunch of neat features, custom rollouts, and all that stuff, you're simply not going to be able to get the same value (unless you have HUGE scale) building it, and should just buy it.
Most organizations aren't comfortable saying "this is all we'll ever need" and are worried about both building, buying, and then migrating, which can be significantly more expensive than either of those options in a vacuum.
In my experience, integrating a thing like feature flags is a major pain if you do not have control over the implementation. It ends up being kludges and suboptimal choices everywhere.
Agree with @Aeolun's comment. Feature Flagging is one exception in buy vs. build where there just isn't any good SaaS out there that makes it "just buy it" worth it. More so if you need customizations beyond what is offered.
Yeah, hosting feature flags in some service is pretty easy (just use ParameterStore!). The hard part is actually using the flags in your application code, which I don't think is something that is easily solved in general
However, if you want a bunch of neat features, custom rollouts, and all that stuff, you're simply not going to be able to get the same value (unless you have HUGE scale) building it, and should just buy it.
Most organizations aren't comfortable saying "this is all we'll ever need" and are worried about both building, buying, and then migrating, which can be significantly more expensive than either of those options in a vacuum.