Np nie ma żadnej kontroli nad opóźnieniem pakietów.

Niby tak, ale nadal opóźnienia te są minimalne - liczone w ułamkach milisekund. Jeżeli nie ma połączenia z fizyczną warstwą wykonawczą, tylko jest jakieś buforowanie, to nie ma aż takiego znaczenia.
Co do "dobrej woli" miałem na myśli raczej to, że pecet się nie zawiesi z byle powodu - przychodzą złe dane -> pakiet do kosza. Przy USB miałem z tym problemy, zwłaszcza z chipem FT232 - na obecnym sterowniku (z optoizolacją) zwiechę miałem dopiero jedną, ale na poprzednim (bez izolacji) był to poważny problem. Po zawieszeniu jedyny sposób na odwieszenie programu na PC to wyjąć i włożyć kabel USB od sterownika.
Fakt, że coś takiego w ogóle może się stać, przy dowolnie złym okablowaniu, jest dyskwalifikujący dla zastosowań przemysłowych.

Wiem, że to jest wejście na wyższy poziom abstrakcji, ale najlepszym rozwiązaniem jest Ethernet. Drivery są bardziej ogólne, niż w przypadku USB - do tego dochodzi brak założenia dobrej woli po drugiej stronie kabla. Efekt jest taki, że driver Ethernetowy właściwie nigdy się nie zawiesza ani nie wywala błędów. Po prostu uszkodzony pakiet ginie i tyle. Przepustowość 100Mb/s też powinna zadowolić każdą obrabiarkę.