Just a follow-up as it's now a week since I put in the USB3->ethernet adapter; it's been working flawlessly under heavy loads for most of the week, both ways, simultaneously etc. also including to/from a VMWare virtual machine on the hackintosh host using bridged networking, and with IPv6 re-enabled (which I don't think made a difference either way, in the end). I've not had a single problem (though sods law dictates it'll fail two minutes after posting this). I've also continued to be unable to reproduce the fault on a real Mac Mini, though I haven't used it as heavily. It does certainly seem to exonerate the higher levels of the Yosemite network stack and point the finger back at these two drivers.
... which seems to be implicit in Mieze's announcement of work on a newly-developed version of the Intel driver. Much welcomed. My only thought, given both the Intel and RealTek drivers were having what looked like the same problem, was that they were both based on Linux drivers, and maybe - I can only offer in a vague way that I'm sure has already been considered - there's something in that that's more platform-specific than it outwardly appeared. For instance, process/thread/scheduling behaviour is exactly the sort of thing that's going to be where Linux and OS X differ in the gnarly detail. (Certainly this machine had been running Linux for a number of months before I turned it into a Hackintosh, and so presumably using the original Linux version of the relevant driver, with no problems whatsoever.)
You are right with regard to the fact that Linux and OS X drivers widely differ. There is a lot of stuff in Linux drivers which makes no sense on OS X or even does harm to the OS.
But I have to contradict the fact that the loss of network connectivity is caused by the driver because I have evidence that it must be the network stack as all of my drivers have a built-in watchdog timer, a software timer completely independent of the NIC, which fires when the NIC still has packets to transmit and there hasn't been any progress for a few seconds. Several users have reported problems with loss of network connectivity and send me kernel log files but I haven't seen a single one in which the watchdog timer fired in such a situation. Obviously the network stack stops feeding the driver with packets in certain situations. Maybe it's running out of buffer memory or the output queue gets stuck, who knows?