It absolutely does fetch because it has rendered. The route changes (or user clicks, whatever), a new component renders and it fetches the first time it renders. This is not a technicality, which is why the thing is called useEffect.
Except your first useQuery call happens before the component it’s in even returns any JSX for React to render.
And you don’t need a useEffect to do this sort of thing. You just need a function that creates a promise keyed to whatever identifier you passed in and some state to hold its status and result.
Yes you don't need useEffect. But the alternative is something like redux, where you're components are not (self-contained) components anymore. And the docs recommend effectful libraries.
Things render after they've generated what they want to render, not before. If you want to render the result of 2 + 2, you have to run that calculation before you can render the result. When you call useQuery, you immediately and synchronously get the status of that query so that you can use it when generating the JSX you're returning to render.
And a side effect and useEffect are not at all the same thing. You're conflating generic software terms with APIs that have very specific meanings and functions within React.
And if instead of calculating 2+2 you call into some world state (or return a deferred call along with your JSX, doesn't matter), then that is a side effect. Period. The main effect is returning JSX (html and some event->callback descriptors), which could be pure.
useEffect is a side effect in a render function. Not all side effects are useEffect in a render function, good job.
Not sure how this got so absurdly reductionist. The fact remains, you do not need to use useEffect to fetch data in React. And useEffect runs after rendering, so you'd be delaying the fetch for no reason.
It does not fetch without rendering, once.