(the folder structure that Orbiter_ng uses is slightly different than Orbiter.exe, so the files are not really where SC3 is expecting them to be)
I think this is not true. Orbiter_ng uses the same folder structure, but is started in a sub-folder, so the directory of the running executable is a different one (the working directory seems to be the root path, though). Unfortunately, SC3 does not respect the Orbiter directory parameters when opening files, it just assumes that it is a fixed relative path based on the directory of the executable path.
Even if it wasn't for the OVP discrepancy, I'd say that this behavior is a bug in SC3, because it should respect the configuration settings. If one customizes his Orbiter installation with e.g. "ConfigDir = .\CharlyBrown\", Orbiter itself would load configurations out of the /CharlyBrown/ folder, while SC3 would fail. BTW: SC4 seems to have the same problem.
Funny thing is: even Orbiter's stock planet modules (e.g. Sun.dll) fail to respect that setting in both 2010 and 2016 versions.
In the genericvessel project, we implemented a function to get an appropriate path from Orbiter according to the configuration settings, so the SC3 bug did not apply there (aka no need for symbolic links). I suggested this change to the author of SC3 when I dropped the project, so it would be interesting to hear if that found its way into SC5. I suspect that this is not the case, though.