This is really the crux of it - jME offers a similar PBR system to other engines, and PBR lies at the heart of modern graphics. However, your graphics will only be as good as (a) the assets you use for rendering, and (b) the lighting information you feed the PBR shaders. As far as (a) goes, Unity and Unreal have extensive stores of PBR based models, textures, etc. If their individual licenses allow, you can use them in jME though they’ll likely require conversion in Blender to GLTF (unless they’re already in GLTF format, in which case you should be able to import them straightaway). jME also has the standard light probes available for (b), and while I’ve not used Unity I believe the feature set is comparable - jME does have a full standard PBR pipeline. Unreal’s graphics will tend to exceed both Unity & jME because they use a number of advanced in-house techniques that go beyond what simple light probes can do.
At the end of the day it all comes down to your preferred toolchain. If you’re OK with Unreal & want the best graphics in the least amount of time, it’s probably the direction to go - but if you want anything custom you’ll be writing C++ or Blueprints. Unity & jME are probably about a tossup in terms of engine functionality, though you’ll find Unity’s GUI tools are well beyond jME’s - but Unity is also highly opinionated about code/game structure, and you have to develop in C#. If you want a “programmer’s engine,” jME is a great fit because (a) you have the advantage of developing in modern Java, which leads the industry in modern cross-platform development, and (b) it’s mature, quite capable, and is easy to do advanced work in without the engine stepping on your toes by insisting that you do things its way. There are things that jME can’t compete with Unreal on, and likewise there are things that Unreal can’t compete with jME on. Deciding which feature set you’re looking for is probably the best way to guide your choice of engine.