The „fallback“ of using the standard mechanism is, in fact, tried first, at JOCL/LibUtils.java at master · gpu/JOCL · GitHub . Only if this does not work, it goes through the (somewhat pain-in-the-back) of loading it from the JAR. So the overall structure matches your code snippet.
The reason for that is simple: During development, it is useful to „override“ the DLL from the JAR with one that has just been compiled and placed into the project directory. It should first try to pick up that one, because it may contain bugfixes that are supposed to be tested.
More generally:
The UnsatisfiedLinkError is the arch enemy (pun intended) of JNI developers. And it comes in several flavors. I’ve listed most (all?) that I encountered until now in JCuda FAQ - Please read before posting .
Fortunately, thanks to the load-from-JAR mechanism from the LibUtils, it basically never occurs any more. (Something like GitHub - scijava/native-lib-loader: Native library loader for extracting and loading native libraries from Java. could be an alternative, but there are caveats…Never change a running system…)
Iff a user still encounters an UnsatisfiedLinkError, then it’s basically always the one that says „The specified procedure could not be found“ (as in this case). This means that the DLL from the JAR was properly loaded (!), but it tries to call a function from the actual, underlying library that does not exist. For example, one will encounter this when trying to call a CUDA 10-function (through JCuda 10.0), but only having CUDA 9 installed.
(Again: In contrast to OpenCL, CUDA isn’t „version agnostic“ in any way…)
(The version problem could theoretically be alleviated by also packing the actual CUDA DLLs into the JAR. But there are two problems: 1. This might cause some licensing issues. And 2.: The DLLs for CUDA are HUGE. The DLL for CUFFT alone has 150 MB, and the total size of all DLLs is nearly 1 Gigabyte. And that’s only one of 3 operating systems. I don’t want to throw 3 GB JAR files into Maven Central 
)