That's why I added the "and I say this as someone who lives and dies by the whiteboard" comment to my answer. Plenty of experience with diagrams. Wouldn't want to code with them for most use cases (and sure, there may be some use cases where visual programming tools make sense - not saying they're aren't any, just IMO, not many).
I'd think it depends strongly on the use-cases and also how the visual language is implemented. Some "visual programming" approaches I've seen simply take a traditional imperative program and turn it into a flowchart - or just show you a simplified AST with some pretty colors.
This is not very useful and often gives you the worst of both worlds - you gain no useful information about the underlying structure but lose many tools to edit the program efficiently.
(Though in highly constrained environments - e.g. high level game scripting - even that can be useful)
On the other hand, there are often cases where some relevant aspect of your program has a structure that could be visualized easily - but not as easily expressed in text. In those cases, I think working with the visualisation can be a lot faster and less error-prone than working with text.
The trivial example is of course GUIs or other things which are visualized in the end anyway. But it is also true for data flow graphs (think Storm or TensorFlow) or networks of things that communicate (Components in an IOT container, services, machines on a LAN, etc).
of course visual programming doesn't magically un-fuck your bad design. If you have a big ball of mud and have a look at the component graph, you'll likely see a tangle of lines that doesn't give you insight. But I think that would be more a sign that you should overthink your architecture, not that visualisations are useless.
Enough to find it not useful for anything more complex than the trivial examples that are always shown to get people hooked. Windows Workflow Foundation, anyone?
