The way you know it's magic is it shatters the principle of referential identity, which tells you that a variable is itself. It pretends you can use a simpler mental model but you really cannot and must not.
"React Functional Components" have nothing to do with conventional functional programming. They inherently (intentionally?) violate the spirit of functional programming through hidden global variables, while pretending that it is still functional, when in reality they should be doing the opposite. They should be upfront about the hack that hooks are. They are not functional, they are merely functions. In all other respects they operate as if the function was a method inside a class and that all hook calls are with respect to an invisible "this" keyword that contains the component's context. Since hooks are not named (which would expose their inherently pseudo-OOP nature), they associate their state through a hidden incrementing counter. It's like you're sweeping all the OOP parts under the rug to pretend to be functional so you can be a cool functional hippie too.
This happens because GUIs are inherently imperative constructs.
The thing is ... you can model effects with the Free monad (or with Haskell's Backpack as was on here just the other day - https://news.ycombinator.com/item?id=45221112), so they are definitely "functional", for most variations on the definition of "functional" that I know.
Functional literally means dealing with functions composition.
Free of side effect is not a property of functional programming. Ocaml is functional and has side effects.
Next you're going to complain about the fact that the compiler handles static variables with controlled allocations for you in C.
Like there's no rational basis for your complaints or critique other than grandstanding.
When you do a useValue() it is clear you are grasping at something with a larger lifespan than your function.
Conceptually it is not much different than
int counter() {
static int x = 1;
return x++;
}