In this example I would rather be worried about the additional latency/overhead of copying all the packets to user space and back.
In my mind the bigger issue is limited throughput, packets per second are fundamentally limited by this approach (tun devices, at least in linux, are generally limited to a single packet per read). Ted even alludes to a 25% reduction in traffic, though it's unclear to me what the link speed is (likely 100M or 1G). In my experience, even with the latest and greatest in linux, you're not going to see reasonable packet rates, and you're still better off doing this type of stuff in the kernel.
That said, tun devices are super cool, and a great tool for anyone to have if they need to do weird stuff like low-level network testing, so I think this is a really cool post. You can read more about it for linux here: https://www.kernel.org/doc/Documentation/networking/tuntap.t...
I presume that under circumstances such as this you end up generating a lot more network traffic than you need to, because of the overhead in retransmitting failed packets.
I know you couldn't buffer indefinitely because your buffer would overflow, but could you maybe delay the acknowledgements of packets, e.g. To simulate a slower link.
Not saying there's anything wrong with the approach or article, merely curious from the perspective of a non-networks guy.