We took the dynamic library path back when we integrated onnxruntime in one of our EQs a few years ago. ORT builder did not exist back then and our attempts to build a static library version of the onnx runtime failed especially due to clashes with the static linked protobuf dependency all our plugins have which clashed with the protofbuf version integrated in onnx runtime, which was of course incompatible with the version we used… This was such a big pain that we didn’t revisit that topic again since then and successfully sticked to the dynamic linked library approach.
We compile onnx runtime with a few custom tweaks ourselves and prefix the names of the resulting dynamic libraries with our company name and add a version number to it. Over time we updated to a newer version of onnx runtime to be able to access newer features in newer plugins. So far there were no problems running multiple older and newer plugins in the same host in parallel which both each link against their own onnx runtime version.
Not sure if you maybe mean us with that, but on macOS we definitively do that 
This is relatively easy to accomplish by modifying the install name path of the dylib and then indeed put it in a custom location. I’d need to scan through some build scripts to find out the exact command for that. On Windows we didn’t find a similar solution so we ended up installing our libraries in System32. What we didn’t know at that time was the Linker support for delay-loaded DLLs | Microsoft Learn approach which makes loading DLLs from a custom location also possible on Windows. juce::DynamicLibrary is an option if you load a bunch of function symbols from a library exposing a pure C interface. However with a complex C++ library like onnx runtime this is not really a suitable option. As you might know, C++ symbol names are mangled following a platform specific pattern which makes it hard to load such symbols manually from a library on the one hand and if you should succeed it’s really difficult to handle member classes and member functions correctly. So no, I wouldn’t suggest exploring that route
That all being said, depending on the complexity of your projects I’d definitively suggest to consider static linking as it avoids some hassle – while of course increasing the binary size of your plugins a bit.
Hope that helps a bit 