That is problematic because configurations are settings not decisions, which means you need work arounds for edge cases and work arounds for the work arounds. If instead you treat everything as a requirement instead of anything as an edge case then you are forced to make decisions and write the corresponding code. New requirements may necessitate refactoring of current decisions down the road, but the code stays clean, small, and deliberate.
At the most simple you only need three things: a central consolidated point of settings (object), storage (localStorage), and interactions isolated to their respective purpose (handlers).
I have explored this space from nearly every angle. I've tried a multitude of languages and technologies, and there is no place where this has been solved completely and there are always drawbacks to any solution. But that doesn't mean those solutions just exist because their authors were bored. They exist because they actually solve a problem.
I would very much like to see you write a large react application using only the concepts you mentioned. How are you going to deal with side effects? You realize you can't just fire those off willy nilly, right?
How are you going to pass information upwards or across the component hierarchy? Callbacks? Have fun with writing that and reasoning about it afterwards.
> This is such a gross oversimplification of the problem
It is not an oversimplification if proven in practice more than once.
> rarely do I see anyone praising it as it deserves