The problem with ports is you're stuck at the feature level at the time of porting and you inherit all bugs and other issues from the original codebase. It's a non-stop race to keep it synchronized after that. In Java's case, you're also very likely to suffer in terms of performance, especially for these kinds of libraries that handle a lot of raw data and may have SIMD-powered implementations.
A binding on the other hand has a lot less surface to cover, just the public API. You do pay the JNI overhead, but it's negligible for well-design APIs and native FFI support in Java 9 or 10 will completely remove it.
I did an OpenEXR build as a test, the API is extensive and pure C++. Even if you only need the IO parts, there are several classes that require bindings. OpenEXR is a popular format, used by many game engines (e.g. both CryEngine and UE support it afaik) and other applications. It may only be interesting to very few LWJGL users, but still it will be useful to support bindings to C++ libraries in general. For example, Bullet is also a C++ only API.
Anyway, it's not a priority right now, but I'll try to add C++ support to the bindings generator, after Objective C.