I do remember thinking this way, but you must be wary of Chesterton’s Fence.
A React engine is a tool for writing incremental code. That is, code that can be rewinded/resumed or partially re-computed. When you write incremental code you must be extremely wary of unkeyed sets. I am particularly fond of this quote:
…plain, old, indexed arrays are kryptonite for incremental code. Unless you’ve deliberately learned how to avoid them, you won’t get far…
Source
The problem, fundamentally, is that diffing a tree without keys is O(n^3). If you’re writing incremental code, this means that no matter what you do your code will always be intractably slow. The solution is to take a hint from MapReduce and put keys everywhere, all the way down the tree. This is why React has the key attribute, and it’s why (as of recently) LiveView has a :key attribute as well.
With React the components are the units of incremental execution and they are safely keyed. But unfortunately this means you must use a component for everything, like the toggle example in the OP of this thread. There is no way to factor out reusable “logic” that is not a component, and over time, in practice, this became annoying. That is why Hooks exist.
But Hooks don’t have keys, so how do they perform incremental reconciliation? Simple: they are forced by the “rules of hooks” to always line up. They cannot be executed conditionally or variably.
A choice was made to keep Hooks simpler and limit the control flow of component execution rather than to extend the keyed diff model. There are a lot of tradeoffs here and I don’t know the exact reason they made that call, but I believe the answer is buried somewhere in this enormous discussion.
I have come to appreciate the wisdom of this decision over time. If Hooks were keyed, they would effectively be components. But the reason Hooks exist is that, in practice, it seems like there are some pieces of code that are nicer when they are not components. So Hooks are a tool for writing incremental code which is not keyed, meaning it must have “static” control flow. Not static everywhere, mind you, but at the barriers where the code interacts with the rewindable state (the Hooks).
It’s a nice solution. I’m not against exploring the state space of alternative solutions by any means, but do try to keep in mind the reasons why things are they way they are. Hooks are actually pretty good glue for incremental and “regular” code.
