I’ve been meaning to respond since you first posted this topic, but I’ve been very busy this last week and didn’t have a chance.
The only “hidden trap” that I can think of off the bat is that if you write code like:
you have to be very careful not to alter the fields of the vector since then ALL references to UNIT_Y would be referencing your altered vector (which probably wouldn’t really be UNIT_Y anymore).
I think it’s highly unlikely that you’ll run into any performance issues with JME that you wouldn’t get with any other language/framework. The hard work in games is usually rendering, and that’s all going to straight OpenGL. If you need something that’s computationally expensive, there are OpenCL bindings available. And, as you mentioned, if you absolutely need to you can link to a C++ library (suggestion: use JNR (Java Native Runtime) instead of JNI - it’s MUCH nicer to work with and you don’t need to build/compile a wrapper around the underlying library).
You’re correct that jME can’t make WebGL content right now. That said, having worked with WebGL outside of jME I don’t really think it’s a loss. WebGL (and the JS/web browser environment) ties your hands on a lot of things, and I remain unconvinced that being able to stick 3D content in a webpage is really such a wonderful thing to do. It’s also MUCH easier to hit performance traps.
You don’t need to use the jME SDK to write jME code. I use Eclipse for coding, and you can use the SDK or @javasabr’s outstanding jMonkeyBuilder editor just for managing your 3D content. As far as the Java language goes, you can use any JVM language you like to write jME games. You might like Kotlin. It’s got clean and concise syntax and isn’t as verbose as Java, and it borrows a few features from C# that Java doesn’t have (like extension methods). Having done 3D work with both Java and C++ (and non-3D work with C#), I can say that Java and C# definitely beat C++ for ease of use. There are only a very few niche areas where I’d consider using C++ over Java or C#, and those are usually already covered by good libraries (like OpenCL).