What is the motivation behind featuresets? understanding tradeoffs

This question is a bit of a follow up to my feature request: #13592.

Let me start by stating I find featuresets very elegant and developer friendly. I can imagine a ton of use-cases becoming easier to implement because style creators have made them part of the style's design. Like I said in the other issue:

The new Featureset concept is pretty clean as a way to curate an API for imported styles. But of course, it comes with the tradeoff that developers can't just mess with whatever they want anymore, and so it limits the things we can build.

I wanted to open this question to try and understand the choices made around featuresets. In particular, why is it now the only way to interact with imported styles? Would it have been better to make it an additional layer for extension, instead of a replacement? Because we now have to open feature requests for thing we could do ourselves before Standard.

I am very much open here by the way, it is not a complain. I'm curious if there is a cost to supporting a full access to the layers like there was before? Maybe it makes it harder to improve core features implementation because it could cause breaking changes? I'd love to understand the choices that were made better, and I think it would allow other devs like me to accept the tradeoffs more easily.

Thank you for any attention this may get.
✌️

Start by reading the linked feature request #13592 and this issue's discussion about featuresets, imported styles, and API tradeoffs. No file, entry point, or test is identified; done would require an agreed rationale or documentation explaining why featuresets replace direct layer access and what tradeoffs that creates.