There's no good predictable event-driven polling library for networking because the whole runtime is a good predictable event-driven polling library for networking. You're not supposed to "event" Go I/O.
Virtually every Go program that anyone has deployed at scale has scaled I/O with goroutines (though not necessarily with "concurrent memory access").
With the exception of NTP, I can't see a single example of a service in the list I provided that is sensitive to "GC pauses" on the scale you'd end up with in an idiomatic Go program.
You are not doing event-driven programming just to scale I/O, you are doing it to avoid mutexes and concurrent memory access, to have easy cancellation, easy management of connections and other resources, etc.
Idiomatic Go code also doesn't use mutexes and concurrent memory access, unless you're trying to argue that channels are implicitly mutexes. Also: you now seem to be subtly backing off your original point. Can we stipulate that the performance of most network programs would not be meaningfully improved by switching from M:N I/O scheduled threads to async I/O?
My original point was about _predictability_ of performance and accidental complexity, that M:N threads with synchronous APIs introduce. But either way, they use way more memory, than necessary and also have to implicitly and explicitly synchronize every little thing, so performance on any meaningful load is going to be very meaningfully worse, than that of event loops.
Still, I want to reiterate, that event loops in modern languages are more about managing complexity, than performance.
Virtually every Go program that anyone has deployed at scale has scaled I/O with goroutines (though not necessarily with "concurrent memory access").
With the exception of NTP, I can't see a single example of a service in the list I provided that is sensitive to "GC pauses" on the scale you'd end up with in an idiomatic Go program.