The WHATWG Fetch Standard is an essential part of the browser networking subsystem. Basically any API that involves networking (e.g.,
<a href> (through navigation),
WebSocket) goes through Fetch. The exception is WebRTC’s
RTCDataChannel and perhaps not surprisingly it has a security issue. The
fetch() API is also defined in terms of Fetch and the similar naming has led to some confusion. Fetch is basically the subsystem and
fetch() is one of the many APIs that exposes (part of) the capabilities of Fetch.
The basic setup is that an API prepares a request, which consists of a URL and a number of variables, feeds that to Fetch, and at some point gets a response, which consists of a body and a number of variables. Fetch takes care of content security policies, referrer policies, invoking service workers, credentials, cache modes, CORS, HSTS, port blocking, default headers (and whether they get exposed to service workers),
X-Content-Type-Options: nosniff, and more. In part Fetch defines essential infrastructure such as CORS, redirect handling, port blocking, and overall terminology, and in part it serves as glue between the now numerous standards that together define the browser networking subsystem.
E.g., for redirects, Fetch defines which headers are preserved, whether a request body gets cloned and reused (it usually does), how the referrer policy gets updated, what happens with redirects to non-HTTP schemes (fail, except when navigating sometimes), but the actual connection opening and request transmission is largely left to TLS and HTTP. And as a consequence of all APIs using Fetch, redirects behave the same throughout. There are exceptions to the rule of course, but redirects are no longer a problem we need to solve on a per-API basis. And when you extrapolate this redirects example to content security policies, referrer policies, service workers, and all the other little things Fetch takes care of, it should be clear why it is essential.
(See Fetching URLs for an earlier introduction.)