Could it be more than this, though? What I've seen about the UiP issue is that (1) the UiP implementation is slower due to strict memory limits, but that should not be noticeable for simple communications like sending individual commands, and (2) the serious issue with the delayed ACK is supposed to be solved by splitting packets in two parts, which results in overall (slightly) slower behavior but does not fall prey to the 500ms-per-packet timeout if an ACK is sent before the processor is ready to receive it. The packet splitting is definitely enabled in the code, so the Smoothieware implementation should not have that problem.
And none of this really matches up to my experience of up to 10 second timeouts.
I notice that up front in libs/USBDevice/USBDevice/USBHAL_LPC17.cpp there is a call to NVIC_EnableIRQ(USB_IRQn), and in libs/Kernel.cpp there is a call to NVIC_SetPriority(USB_IRQn, 5). So the USB interface appears to be interrupt-controlled. But if I do a search for ENET_IRQ in the source code, I come up with nothing other than the definition of the IRQ number. It appears that the ethernet module only processes incoming packets during on_idle(), not by interrupt. Is that intentional? I admit that I don't really understand the code all that well. The irq routine is all commented out, and I assume that's on purpose.