The main target of the Godot Engine are game developers. But Godot's easy workflow and functional UI elements, makes it also a good fit for non-game applications. There are already some out there you may know, like Pixelorama, an Open Source 2D sprite editor.
There's tends to be one major difference between games and non-game applications, so toolkits designed for one are often quite unsuitable for the other.
A game generally performs logic to paint the whole window, every frame, with at most some framerate-limiting in "paused" states. This burns power but is steady and often tries hard to reduce latency.
An application generally tries to paint as little of the window as possible, as rarely as possible. Reducing video bandwidth means using a lot less power, but can involve variable loads so sometimes latency gets pushed down to "it would be nice".
Notably, the implications of the 4-way choice between {tearing, vsync, double-buffer, triple-buffer} looks very different between those two - and so does the question of "how do we use the GPU"?
Without much experience building UIs aside from web, my limited experience with Godot leads me to believe that building an application this way would lead to a lot of decentralization of logic, which might be a bad thing for complex applications. For example, various UI elements might have a bunch of logic attached to them instead of having a centralized place where the logic lives. I guess this happens in web too, and maybe native UI frameworks/toolkits?
My 0.02 - I've been developing a code diagramming tool in Godot. It's been really nice to work with. I think its much easier to build a decent App UI in Godot than in, say, Android or (fucking) Swing.
It's not as expressive as the combo of html/css/js, but it's also much faster to get something useful put together with standard widgets.
I've been able to put together a combination of a text editor, buttons, menus and then my own custom graph-drawing widget.
Highly recommend!