He probably spent more time figuring out if the suggestions are usable than he would have needed to just implement those manually.

I guess if he wrote tests first it would have said. no method called x in util. TDD helps take a lot of thinking out of problems.

Why does this need nf_queue? Wouldn't it be sufficient to directly filter the connect syscalls using eBPF?

Dropping packets using netfilter makes many applications wait for a timeout. I prefer reject to filter unwanted outbound connections so that applications don't wait.

This uses NFQUEUE to get real-time userspace access to the ability to decide which connections to allow. NFQUEUE users must return a verdict on the packet (skb? I don't recall) before the packet continues to flow through the system. Using seccomp you don't get the opportunity to pass that up to a user to decide which action to take. Using other eBPF consumers are similar (since it represents a risk).

I especially like the aggregator functions, it allows to select an additional dimension of data.