Hooks on the other hand are functions that you call, which implicitly rely on a magic global state and context, and you cannot use them like other JS functions. You can't conditionally call them or change the order of them, because they contain a unique ID based on call order, which is Spooky (and is why React has to build its own ESLint rules to make sure you don't mess it up!).
Don't get me wrong - I do think the ergonomics of hooks are a lot better, but I think at least part of that is due to it being a newer iteration of the API.
You don't put imports in if-s or for-s. It's as simple as that.
There’s not necessarily bad reasons for this, but the cognitive overhead of this is relatively high compared to existing language functionality.
They use subset of function syntax to provide unique functionality. That's all.
JS was full of such things already. Functions that are hooks (in traditional sense of the word) into some platform provided functionality. setTimeout(), fetch api, promise chains, jquery. You could say that all of those are just functions but you still need to learn what each does separately to get behavior you want. JS is not Lisp where a function means just one thing used always the same way with same restrictions. JS uses functions to construct idioms that introduce functionalities foreign to the core language. React hooks are just one such idiom. You may still argue that introducing yet another idiom is unnecessary burden. I personally like them very much. Component classes were imho very bad conceptual fit for react with a lot of intricate lifecycle methods and special fields. Hooks allow to simplify the core of it to just render that just runs every time it's necessary into which you are bringing in additional functionalities as needed.
Lisp uses dynamic binding for that.
(defun do-something ()
(funcall *something-to-call*))
(let ((*something-to-call* 'turn-the-light-on))
(do-something))
The behavior depends on the dynamic binding, which provides the context...