Visual tools are used all the time, take a look at UE4 or Unity, most AAA engines look pretty much like that. Not all engines are as polished as these two (since those are products by themselves so they have to look shiny and do a lot of stuff to cater to a large demographic) and not all engines use the monolithic approach where the editor and the engine are one and the same (AFAIK Sony released a framework of theirs a few years ago for C#/WinForms that they used for internal tools which were completely separate from the engines - a programmer i know who has worked on something similar also told me that the tools even had their own separate renderer). But visual tools are involved in one way or another, especially when it comes to inherently visual stuff (e.g. like you wouldn't manually put pixels in an image and use an image editor instead, you wouldn't put the objects manually but use a scene editor).

How much they go towards visual vs non-visual is largely a matter of engine and tool design. In UE4 everything is done visually, including scripting. In Unity most behavior and scripting is done via C# but the rest are done visually (though there are addons for visual coding and/or behavior too). In a company i worked at some years ago everything outside of scripting was done visually using a combination of in-engine and external (but still custom) tools. In a company i worked more recently almost everything outside of level design was done via text files and there was no scripting at all, all game logic was in C++ and driven via text files (however the editor had a very flexible parametric prefab system which allowed a lot of modularity so you could still have some simple form of logic through reusable components).

In my own engine and editor (you can see both in action here[0]) i have them totally separated - in fact i started wroting the editor three years before the engine and i used it for different stuff (e.g. this little creepy[1] game i made for an old Ludum Dare in Java/LWJGL which i lated used as a base for this Descent-like demo[2] and later in this[3] demo i made to learn C#/XNA). Outside of world editing, everything else is handled via scripts (actually even inside the editor you can 'attach' script code to entities, it is just that the editor doesn't know about them, they are just passed as strings to the engine which handles them as scripts). These scripts are mostly edited by hand[4] or generated by other tools (e.g. the model editor generates scripts that define animation details through scripts) or scripts.

Though recently i'm thinking on scrapping everything and making a more unified monolithic engine. Architecturally i believe it is better to have everything separate (especially the engine from the tools, but also the tools individually) but in practice it is much more convenient when i can reuse existing code - as things are right now, even though i do share code between the tools, i still have to reimplement a lot of stuff that a more monolithic approach wouldn't require. Nobody else except me is going to use that code anyway :-P.

In any case, if you are curious about how tools are used in a game, even if a tiny game made in two days for a gamejam, you can see the two-days-compressed-to-one-hour video i made for the She Loves you game in [5].

[0] https://www.youtube.com/watch?v=8gnDdM_PC54

[1] https://www.youtube.com/watch?v=LeIIt5Wydyw

[2] https://www.youtube.com/watch?v=5WrV4By94pQ

[3] https://www.youtube.com/watch?v=GP9kTbYxIqY

[4] https://i.imgur.com/tCd64Wh.png

[5] https://www.youtube.com/watch?v=YXIDzwUMnIg