It could easily be handled in a seamless way. Have a system default, but also let third-party developers build configuration screens to let users choose when, how, etc. they want to adjustments made. Configuration aside, the only time the third-party code is called is every n minutes where iOS requests "what are the new color settings?" and the app responds. iOS takes those settings and applies them system-wide when appropriate, so (for example) the code is never called when the screen is off, and this would also let Apple provide features such as app-specific exceptions, which the third-party code would have no visibility into. Very similar to how content blockers work for Safari.
In general that's not "the Apple way". When they provide customization points like that (keyboards, notification widgets, share sheet icons) it tends to be after the 'reference implementation' has been in iOS for a few years and the problem has been well studied. Examples where it works very successfully (Android usually) help.
Content blockers are the only thing I can think of off the top of my head that haven't followed this pattern. That may be because it was a feature Apple wanted to improve the experience but didn't want the legal fight that would come with shipping their own blocker.
Thinking of it from Apple's perspective what do they gain from opening up these private APIs? They now have a new set of APIs that they have to maintain, document, and support. Where does the financial justification come from? I honestly don't see "f.lux runs on iOS" being a selling point for most buyers.
