The problem with your line of reasoning is that it's very academic. Reimplementing drivers in user space is a much higher friction task than remote controlling an XDP program via bpf maps, and you're competing with the device manufacturer over implementation correctness in many cases. XDP isn't going to solve driver implementation issues, but it's an incremental step towards low cost high speed networking which is what most people are using user space networking solutions for. It also directly address the in user space packet processing (QUIC, TCP) and makes it safer by enforcing BPF sanity checks and allowing a user space component in Rust.

I agree with what you are saying, it's all true. There are lot's of problems with C in the kernel, but that's what we're currently stuck with. Practically there is only a small difference in the value proposition of rewriting the kernel in Go and rewriting our existing network drivers in userland in Rust, when our use cases are more aligned with what we're getting with XDP.