I currently have the pleasure to rewrite a lot of JNI code with a view to improving the Java to C++ communications performance on my client's project, so there is demand for this sort of skill but it's not something I would bank a career on. At the end of the day it's a small effort compared to the overall effort involved in the project and usually you can create a reasonably working implementation if/when you're fairly competent in both languages. I'm by no means a JNI expert but have a decent background in C++ and reasonable Java.
As some of the other posters have pointed out, pretty much the only reason for existence of JNI these days is so you can glue a library that exports a C interface onto a Java project. In most cases, there is not much of a performance benefit of reimplementing Java code in C as JVMs are pretty good at generating machine code on the fly already. Plus, once you get outside Java, you have the worst of both worlds in the sense that you have to manually manage resources in both C/C++ and to a certain extent in Java by dropping hints to the JVM. It's not a particularly pleasant place to be IMHO and normally you'd try to keep the JNI part as small as possible so you'll transistion from the JNI code into your library as quickly as possible. Basically, you're writing an object translation layer if you use JNI as an interface from Java into C++.
As it has been pointed out there are tools like SWIG that can simplify this task already so as a career path I would think it's a bit of a dead end. That said, I consider it another tool in the toolbox I can offer to my clients and I do think it's useful if you have a foot in both the Java and the C++ camps. People who can do both languages well are pretty rare in my experience so I would concentrate on that instead of the layer that glues them together.