I don't think it is so strange for node to incorporate it as part of their standard lib as well.
1. https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API
"With fetch available in node, we have a single, standardised, promise-based HTTP client Interface available on all (more or less common) JavaScript platforms.
This is great news for an ecosystem traditionally extremely fragmented and may lead the way to more consolidation in the JS library space. "
As someone who has been working almost exclusively on Node.js applications for years now, this is big.
Front-end developers have, for years, enjoyed this wrapper around the clunky XHR API. It is simple, intuitive, and it comes _free_ in the browser environment (and was easily shimmable before it was standard). Additionally, the depreciation of the popular request[0] a while ago, there has been a gap in The Right Way to do http requests without going into the low-level API that ‘http(s)’ provides. Fetch is promised-based (enabling seamless async/await) and, most importantly, standardized.
Basically, fetch provides a meaningful abstraction atop each platforms’ implementation of http-request-doing further unifying server-side and client-side patterns and idioms.
“I'm curious why Node core has decided to make this an official part of Node?”
The standard describes many functions and classes. What makes fetch more land-able than e.g. the event system, of which node has incompatible implementation? Or feature detection via navigator. Why it? What were the main point(s) of adding fetch specifically?
If something is standard, and it makes sense in the context of a backend, then it's convenient to just use the same API on both ends. Navigator makes almost no sense on the backend unless maybe it worked as a dummy polyfill object.