I guess I am the one here who has used way too many game engines (and has time to blab about it). 
I used Godot for a year or so before switching to Defold. I made 1 finished game, 2 half-finished games, and several prototypes with it. This was a while ago, around the time they started working on 3.0, so some of my experience may well be out of date, but I doubt the general things have changed.
I already wrote some posts related to it:
Regarding productivity, I think Godot and Defold are pretty equal, but they require slightly different methods/mindsets. Godot has a lot more features out-of-the-box than Defold, so you may find it faster in the beginning. Defold, instead of trying to handle everything anyone will ever need, is more set up to use external libraries for game-specific features. Grab a few libraries from the community asset portal and you will be off to a pretty quick start. You can also grab any Lua code that other people have written for general purpose or other Lua game engines and use it with Defold with little or no adaptation. Some people don’t like using other people’s code that they don’t understand, but let’s face it, you’re doing that either way.
So it’s a trade-off. With Godot you have lots of features ready-to-use, but if they have bugs or don’t work quite the way you want, you can’t fix or change them without editing the source code and compiling the engine for your platforms. With Defold, you have to find libraries or write things yourself, but if they’re not perfect you can change them just as easily as you can change your game code, and they will work on all platforms.
I’m a bit heated on this topic and I haven’t used Godot in the last year and a half or so that I’ve been using Defold, so take my word with a grain of salt, but here is…
A long rant about Godot...
Godot has some nice core ideas (the scene/node system), plenty of features, and is fairly easy to learn, but it’s also bug-ridden, slow, has very incomplete documentation, and a cultish community.
Bugs:
Hopefully it’s gotten better as the community has grown, but when I was using it 90% of the engine development was done by Juan (reduz). He pumps out code amazingly fast, but he also doesn’t pause to test it or document it, and he rarely goes back to fix old code. There’s a strong focus on adding new features, very little on fixing things. His most common response to serious bug reports was “oh yeah, there’s no point fixing this, I’ll be rewriting it for 3.1”. So there are lots of broken or unfinished features lying around. There’s really no such thing as a stable release of Godot.
People think the open source thing is awesome, but to be honest I’m not sure if it is more positive than negative. They routinely use it as an excuse for terrible documentation and sometimes bugs. Several times I (or other people) asked for help on how a feature worked and the answer was: “I don’t know, go read the source code and let us know what you figure out”, or “if it’s broken, feel free to fix it!”. Also, there is no great review process or testing for code to get added to the engine. Random people write stuff, add a pull request, and chances are, it is added to the engine a day or two later. I was in a discussion once about how modifier keys were handled. Some guy decided he knew the solution, wrote some code, and the next day or so it got pulled into the engine. But all it did was move the problem from one place to another! As far as I know there’s nothing in place to stop this from happening constantly. It looks like they don’t use unit tests or any other kind of code testing (at least not with any consistency).
Slowness: (scripts)
GDScript is slow. I haven’t done any tests in ages, but I am confident if you test the same code between GDScript with Godot and Lua with Defold, Godot will be 10x slower or more. This won’t be noticeable when you start working on a new project, but as things get more complicated and you add more and more scripts, you will see the framerate slowly get lower and lower. I think someone did a test when they started adding support for other languages and the others were significantly faster, but I don’t know the specifics. This has been tested and reported multiple times over the years, but the Godot devs have simply denied that the tests were valid and haven’t shown any interest in trying to find bottlenecks and optimize.
Slowness: (rendering)
Godot also seems very slow about rendering. As far as I can tell, it still doesn’t do draw-call batching at all… You can kind of get away with this on desktop, but mobile devices can’t handle it. See here, here, and here. Some quotes from Juan regarding 1000 draw calls: “This number of draw calls is not much of a problem in OpenGL. Batching is not really necesary.” and “…might be better to eventually wait for phones to get better than fixing this.” For comparison, with Defold it’s pretty easy to stay below 50 draw calls for everything in your game. Also it has overdraw issues. I was working on a platformer and wanted some parallax backgrounds, but I simply couldn’t draw more than two layers over large parts of the screen before the framerate dropped below 60 (with everything else going on of course). I recently tried something similar with Defold and it had no problem drawing a dozen or so overlapping screen-sized images. It’s quite possible that Godot doesn’t do any depth sorting either, which could be the problem.
Documentation:
Godot has a pretty sizeable community to ask for help, but its documentation is very bad. To start with, a lot of it doesn’t exist. When I was using it, they announced that 60% of the class documentation was missing. 60%!!! And that’s just the stuff that doesn’t exist at all. The stuff that does exist is far from being good documentation. Most of it just reiterates what the name of the function already tells you. It doesn’t necessarily tell you what units all the arguments use, what each argument does, what the corner cases are, and almost never has examples of use. This is just the API documentation, never mind actual manuals that tell you how to use things in a pleasantly readable way.
The community has made some valiant efforts, but I don’t see how the situation will change much. New features are added without proper documentation. Unless that changes (either by not adding any new features or only adding them after they are fully documented), it is a losing battle. No one should have to delve into the C++ source code to figure out how a feature works.
and:
A few more opinions about Defold.
Defold isn’t perfect either, but it is light, fast, relatively bug-free, has great documentation, and very active and helpful staff and community support. Releases generally include more bug-fixes and small improvements to old features then added new features. I’ve seen occasional serious bugs reported on this forum get fixed within a couple days or a week. You don’t have to worry about new releases breaking your game without warning or having new features that don’t work correctly. I can’t begin to say how valuable this is. I’ll take a small core engine that works reliably over a big, untested engine with all the fancy features in the world.
I basically detailed the main things I don’t like about Defold in my post about Love in your other thread. (just invert the things I like about Love.)
(To sum up: poor desktop support, limited physics, and very limited audio.)
Defold’s platform support and build process is generally better than Godot’s, except that Godot has more desktop-specific engine features. I guess Godot has working web builds now, but from what I’ve seen they’re not as small and fast as Defold’s. (Defold is heavier than a dedicated web engine though.) Defold has quicker and easier builds for desktop (as you’ve seen), and makes it very easy to build and test things on mobile.
