Right now the spec the spec mentions at the bottom of 4.2.4.3 Obtaining a resource from a link element that the task source for the "error"/"load" events is the DOM manipulation task source. Given the aforementioned events are primarily network-based, it might make sense to queue these from the networking task source instead.

Aside:

I created this gist to see if I could observe the "load" event of a link element that is blocking the pending parsing-blocking script of a Document, before the script's execution, and even further before the DOMContentLoaded event is observed. Given the gist, Chrome gives the following in the console:

async script start
async script end
Pending parsing-blocking script now executing
DOMContentLoaded
<link> load event fired

while Firefox yields:

async script start
async script end
<link> load event fired
Pending parsing-blocking script now executing
DOMContentLoaded

The latter makes more sense to me, since for the inline script to run, the link event has to be loaded, of course. The spec is written this way, and Chrome is currently non-compliant (there are actually two issues with Chrome, DOMContentLoaded is fired synchronously and the networking task source is actually used for the link element).

However, Anne makes a good point in that networking-driven events should come from the networking task source, which can of course be prioritized in an implementation-dependent manner relevant to the DOM manipulation task source. This example is a specific instance where it would be convenient otherwise, but his point overall makes sense.