This is an interesting point. In Arroyo [0] (the streaming engine I work on) we also use a simple TCP-based backpressure mechanism: we have NxM TCP connections between each operator subtask, behind small in-memory queues. This essentially is relying on the kernel's flow control and backpressure mechanisms instead of building a custom network stack like Flink does.
This has worked well in practice, but I think does leave some performance on the table and likely incurrs higher resource utilization. Flink for example uses a system of "floating" buffers that can be moved between streams as needed to minimize the total number of buffers needed.
However it may be that Linux's network stack has gotten good enough at this point that it makes sense to just rely on it directly.
I wish there was more research out there on how these sorts of network stacks should be built on modern hardware and OSes.
(semi-relatedly, was checking out your CV; a bunch of great looking papers there that I'll definitely be checking out!)