The columns look fine and shouldn't cause any trouble. CPU shouldn't be an issue either if the usage is so low.
It's possible the Linux server at the other end doesn't support the FIND_FIRST_EX_LARGE_FETCH mode which we use to speed up directory reading on network shares, in which case there would be a network roundtrip for each file, instead of reading them in batches.
That mode is also only supported on Windows 7 / Server2008 R2 and above, which could be a factor if the machine is an earlier version, or if compatibility settings have been set on the Opus EXE to make it think it's on an earlier OS.
You can check that via Help > About Directory Opus and then click the Copy button. The text it puts in the clipboard will include the OS version it believes it is running on:
Directory Opus Pro 12.11.1 (Beta) Build 6955 x64
OS 10.0 (B:17763 P:2 T:1) SP 0.0
Path lengths may also play a part in how the local OS and remote server talk to each other. If the file paths are over 255 characters long (including the filenames) then it might be worth checking if the same issue happens with a similar number of files but with shorter names and paths.
When you compared Opus and Explorer, did you try Opus after Explorer or before? Directory listings may be cached if another program has read them recently, so if you test two programs, one after the other, the second one may be much faster due to caching.
If none of the above leads anywhere, it might be worth generating a couple of Process Monitor logs, one of what Explorer does when reading the folder, and another of Opus. (No need to log the full 2 minutes; the first 30 seconds or so should give us plenty.) If you do that, please let us know the path of the folder so we know what to look for in the logs. Here are instructions on how to make Process Monitor logs: