They way this is set up it's enumerating systems and ports on internal networks, not actually
accessing those systems and ports. The CORS header (or lack thereof) in the HTTP response of the
requested item is what dictates whether it can be accessed, so what happens is the request first sends a HEAD request to get the headers for the endpoint, and then if CORS is set up and allowed for cross-domain access is allows the connection (or if it's a request to the same domain and CORS for the current page isn't too restrictive, it allows the initial request without a HEAD request).
What you see in the browser developer tools if you open them up is that a bunch of requests are being made, but are being denied because they are failing CORS checks.
Where data is being leaked (in context of security) is that there's a difference in how the responses are handled. Either it's allowed (because the remote side CORS is too loose) in which case the page will show s message that the specific host/port combi is available, or it will get no response and time out, in which case they skip checking that host any more and assume there's nothing at that IP (which is when they print the "unreachable" message), or it continues on with the next port. If at the end there's been no success and no timeout, it prints the "complete" message, and that means there's probably something at that IP.
An important thing to note is that CORS is not like a firewall, and it doesn't actually stop all traffic from happening, so that can sometimes be used to get additional information that's not necessarily meant to be exposed. That said, what the page is showing is that the specific way CORS functions (that is, asking the remote side if they accesible), and the fact that Javascript runs locally on your browser, means that there's some interesting ways those interact which can cause security concerns.
A as idea of how this could be used to more nefarious ends, if it found listening and accessible servers on localhost or the local network, it could then try to identify them based on the headers/content returned, and try to do something with that.
Given that you could possibly even compile some network vulnerability scanner/exploiter to WASM and use it for only the subset of vulnerabilities it could accomplish through plain HTTP requests (a lot of work, it's probably easier to just write your own shim and crib their exploit library), this could be very easily weaponized.