On @MeFisto94's request, I'll write down some stuff I find easier to do in Godot than JME. Do note though, I've only made a couple experiments in Godot, farm from the amount of experience I have with JME.
1. Scene Graph Editing
It can technically be done in the SDK, but quickly throwing together full scenes as wanted is almost impossible without coding in JME. The farthest the SDK can currently go IMO is fixing some orientations and materials on import. As long as you stay with Nodes and Geometries it's fine, but as soon as you go into lights, particles, sound... the SDK falls flat.
2. VR Support
Let's face it, JME-VR probably needs a complete rewrite.
3. Material Editing
I had the SDK one completely give up on me every so often, especially when writing custom shaders. It also has unnecessary left/right sliders in the non texture section of the material editor, which really annoy me for some reason. The fact that the material editor in the SDK is by default in a different tab than the scene composer and you can't have both shown at the same time doesn't help either, as PBR materials consist out of a lot of guesswork and seeing the changes on your intended model in real time is important.
4. Networking
Godot's networking system is higher level than JME's. I could never wrap my head around making a simple multiplayer room where multiple players can move around with just sending messages which I would have to write manually etc. In godot most stuff is a single RPC away. GDScript keywords for master/slave variables help a bit too.
This might just be a documentation issue though.
5. Animation
Godot comes with a full animation editor, almost like Blender, which allows keyframing of pretty much any number, including variables. Oh, and calling a function in your code on a predefined keyframe is cool as well.
6. Graphics
Global ilumination, SSR, a decent looking bloom, HDR, etc. JME just lacks in the eye candy department. Most filters JME has, are stuck in 2005.
I'm aware Riccardo is brewing a new pipeline, so the situation might improve in the future.
7. Environment
Setting up the environment in JME is cumbersome. Load a HDRI as skybox, then manually generate a light probe, then add an ambient light to fix the intensity. Or just do it in a single UI panel in Godot. Not to mention procedural skies in Godot.
8. GUI
I know it's not exactly comparable, as Godot was, until not too long ago, a primarily 2D engine, but in JME, making a GUI is a pain I rather avoid unless I'm making something I intend to publish. In Godot it's literally dragging a couple elements to the canvas. It's also a big difference that you can see your gui in the editor. In JME you have to launch your game, wait for it to open (which can get long when your game has a lot of assets to load), figure out your text is 3 pixels too far to the left, close the game, tweak the code, repeat. We literally had a launch argument in LSF which only loaded the GUI to minimize the wait.
For me, this results in different approaches to developing. In JME I just hardcode the values I want while testing, while in Godot making a GUI for setting them might even be faster and certainly much more flexible.
That's just some stuff I could remember from the top of my mind. I'm sure that when I dig in more, I'll find more stuff that I find better in Godot.
And while I'm at it. Please stop with the "well X feature can be found in a plugin from the asset store" mentality. There are some things people expects for a proper game engine to just have. Without having to download (unmaintained) plugins from third parties.
On @MeFisto94's request, I'll write down some stuff I find easier to do in Godot than JME. Do note though, I've only made a couple experiments in Godot, farm from the amount of experience I have with JME.
1. Scene Graph Editing
It can technically be done in the SDK, but quickly throwing together full scenes as wanted is almost impossible without coding in JME. The farthest the SDK can currently go IMO is fixing some orientations and materials on import. As long as you stay with Nodes and Geometries it's fine, but as soon as you go into lights, particles, sound... the SDK falls flat.
2. VR Support
Let's face it, JME-VR probably needs a complete rewrite.
3. Material Editing
I had the SDK one completely give up on me every so often, especially when writing custom shaders. It also has unnecessary left/right sliders in the non texture section of the material editor, which really annoy me for some reason. The fact that the material editor in the SDK is by default in a different tab than the scene composer and you can't have both shown at the same time doesn't help either, as PBR materials consist out of a lot of guesswork and seeing the changes on your intended model in real time is important.
4. Networking
Godot's networking system is higher level than JME's. I could never wrap my head around making a simple multiplayer room where multiple players can move around with just sending messages which I would have to write manually etc. In godot most stuff is a single RPC away. GDScript keywords for master/slave variables help a bit too.
This might just be a documentation issue though.
5. Animation
Godot comes with a full animation editor, almost like Blender, which allows keyframing of pretty much any number, including variables. Oh, and calling a function in your code on a predefined keyframe is cool as well.
6. Graphics
Global ilumination, SSR, a decent looking bloom, HDR, etc. JME just lacks in the eye candy department. Most filters JME has, are stuck in 2005. I'm aware Riccardo is brewing a new pipeline, so the situation might improve in the future.
7. Environment
Setting up the environment in JME is cumbersome. Load a HDRI as skybox, then manually generate a light probe, then add an ambient light to fix the intensity. Or just do it in a single UI panel in Godot. Not to mention procedural skies in Godot.
8. GUI
I know it's not exactly comparable, as Godot was, until not too long ago, a primarily 2D engine, but in JME, making a GUI is a pain I rather avoid unless I'm making something I intend to publish. In Godot it's literally dragging a couple elements to the canvas. It's also a big difference that you can see your gui in the editor. In JME you have to launch your game, wait for it to open (which can get long when your game has a lot of assets to load), figure out your text is 3 pixels too far to the left, close the game, tweak the code, repeat. We literally had a launch argument in LSF which only loaded the GUI to minimize the wait.
For me, this results in different approaches to developing. In JME I just hardcode the values I want while testing, while in Godot making a GUI for setting them might even be faster and certainly much more flexible.
That's just some stuff I could remember from the top of my mind. I'm sure that when I dig in more, I'll find more stuff that I find better in Godot.
And while I'm at it. Please stop with the "well X feature can be found in a plugin from the asset store" mentality. There are some things people expects for a proper game engine to just have. Without having to download (unmaintained) plugins from third parties.