Not here, though. The exact code:

  fetch("https://gyrovague.com/?s="+Math.random().toString(36).substring(2,3+Math.random()*8),{ referrerPolicy:"no-referrer",mode:"no-cors" });

"no-cors" means the request will not be preflighted, but also that JS will be denied access to the body. But the body doesn't matter here — the attack only requires the request be sent.

But more to the point, so long as the request meets the requirements of a "simple request", CORS won't preflight it. GETs qualify as a simple request so long as no non-CORS-safelisted headers are sent; since the sent headers are attacker-controlled, we can just assume that to be the case. In a non-preflighted request, the CORS "yes, let JS do this" are just on the response headers of the actual request itself.

Since GETs are idempotent, the browser assumes it safe to make the request. CORS could/would be used to deny JS access to the response.

Things are this way b/c there are, essentially, a myriad of other ways to make the same request. E.g.,

  <img src="https://gyrovague.com/?s=…">

in the document would, for all intents and purposes, emit the same request, and browsers can't ban such requests, or at least, such a ban would be huge breaking change in browsers.