The way references are handled in scene files makes it easy to get conflicts when working on the same scene. In Unity, solving these conflicts is a lot easier (from personal experience, only an issue working in teams).
Animation files sometimes empty themselves when using a composition-based approach. If the object you reference no longer exists (e.g. you programmatically decide what weapon a player uses and don't instantiate anything preemptively) the animation player will opt to rewrite the animation as if that component never existed, resulting in loss of work.
Low level oddities: drawing lines using the drawing system doesn't work if the point is outside view of the screen. You can't specify whether to draw the segment that would be visible if possible.
There still isn't a whole lot of support to release on some specific platforms, and some popular programs don't have a support plugin yet (e.g. Live2D).
The object-oriented structure of each node type can be severely limiting towards a composition-based approach. Minor gripe as it is possible to work around this or implement your own entity-component-system framework or Unity-like GetComponent/AddComponent structure.
It is definitely a great engine and regarding 2D, I'd say it is at least on par with Unity. For 3D and general-purpose, it is still subpar to Unity and definitely subpar to Unreal. Of course, the easy solution to each of my problems is "why not write it yourself?", but that requires time saved when using Unity. On the other hand, I do find Unity to be particularly cumbersome on the final 20% of the project, whereas Godot is much easier to finish a project with.
The last reason you'd want to switch to a new game engine or framework is because it's newer.
And, while I like Godot, the implication that it can replace Unity (much less Unreal) at this point is just ludicrous for anything but bare minimal toy projects.
>You can script it in pretty much whatever language you want.
Yes, no and maybe?
Someone has to write the interface for each language and be willing to update it with each version of Godot, and all existing documentation and tutorials reference GDScript and maybe C#. There are language forks out there but I'm unaware of any projects being completed with them, so their stability and viability is questionable.
That's going way too far in other direction. IMO Godot can support any kind of 2D project and deliver polished and performant product. In 3D medium the competition is too far ahead with ready-made assets and robust tooling, but complex projects still seem doable.
Currently Godot is used mostly by open-source gamedev enthusiasts and not professional teams with art talent and funding. The editor and engine was not really pushed to its limits.
I agree with your other points though.
I agree that so far no one's really tried pushing Godot to the limit as far as I've seen. But when all you have to go by is the content on /r/godot it doesn't make a compelling argument for Godot as a viable replacement for existing engines yet.
Since then, Unity has grown into a serious contender and while my experience with Unreal is limited to hobby projects I can definitely say I prefer Unity over Frostbite for AAA development.
At this point, I'd like to say that what I said back then now seems to be true for Godot instead.
1. https://trello.com/c/lzLwtb5P/124-vulkan-for-pc-and-linux