We're aware of that famous article from some years ago and have done some of the things in it already.
Is anyone talking about high-latency networks? People usually talk about LANs from memory.
The real takeaway from the article is that Windows allows minor differences in how files are read/written at a high level to have a huge effect on speed in certain situations, rather than making those APIs adapt as required automatically[1]. Thus Explorer (and CopyFileEx) are faster sometimes, but I've also measured Opus performing faster in some tests here. Part of the problem is there is no right answer, and a load of random things we can try will be good for some and bad for others, or may make no difference at all.
([1] For example, if multiple parallel small read requests make sense for a given driver, there's no reason Windows can't split a single large synchronous read into just that behind the scenes. We do some of that ourselves anyway, but it won't all be the same as Explorer as the exact details are undocumented and subject to change.)
But equally important is that the testing is done properly in the first place, with both programs only copying the same metadata as each other, effects of caching mitigated, antivirus/firewall turned off, and enough tests performed to account for speed fluctuations due to other activity. When I do such tests here, the speed is normally very close between any two programs. (That won't always be the case, though, as some setups have pathological cases if you use the wrong buffer size, etc. So I am not saying the speed will always be identical if the testing is done carefully, only that it will be in most cases, and has been in my own testing of various programs, not just Opus.)
Finally, it's worth noting that you can configure buttons to effectively copy files using CopyFileEx from Opus: Copy files via the shell (Windows Explorer). We're considering integrating such an option into Opus more directly, too, for people who want file copying identical to Explorer.