I don't think that the complexity issue (...) is essential. I think it's self-imposed by current visual language designers. Perhaps that's because the handful of visual languages that got traction (and thus the benefit of countless hours of design & development effort) are created for people who aren't computer scientists. These languages only need to be sufficient for solving a domain problem, not for advancing the art of the visual PL.
The fact that current visual languages are built of monochromatic text, a few box shapes, and a few colors of line, is a tremendous failure of imagination.
The problem with visual programming is that you can't have more than 50 visual primitives on the screen at the same time.
The classic problem with node + arrow code is that the complexity of the graphical representation is simpler than the text representation for simple graphs, but grows in complexity much faster than text does. This makes graphs very attractive for demos and extremely painful for real work. Luna's approach tries to get around this by giving two views on the code, but I suspect the better answer is another paradigm we haven't seen yet.
— Jack Rusher
Secondary notation is poorly developed in the box-and-wire notations we examined, which we believe makes them harder to understand (although as yet, large-scale studies of comprehension have still to be reported). To achieve their aim of making better use of the visual medium, VPLs need facilities for colouring, commenting, grouping, modularizing, etc. (We recommend an explicit 'description level'.) Techniques to reduce the cluttered-wire problem would greatly increase the scope for using spatial layout as a form of communication.
— Usability Analysis of Visual Programming Environments - A "Cognitive Dimensions" Framework