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.
