While any LabView code I've ever seen (admittedly not much) looked like a horrible mess to me, I disagree with your view on graphical programming languages.
I've done a reasonable amount of programming in Max/MSP and while, again, most code I've seen online was a horrible mess, I attribute that to the fact that these languages usually target non-programmer audiences who, sadly, don't get taught about proper encapsulation, abstraction, naming conventions (ie use actually descriptive names!) and software patterns.
My own code read (to me - though others have commented on it too) almost like something you'd write on a whiteboard to show how the software works to non programmers. I encapsulated each chunk of code that does a single task into its own component, so an individual component (ie diagram) never had more than a few high level "things" connected together, so you can tell - at a glance - what does what. Of course, this means that there are many layers of components, from very high level all the way down to low level, but the point is that with proper encapsulation, visual languages are no harder to understand, read or manage than textual ones and I personally feel that, in many ways, they're actually easier.
I also found debugging Max/MSP code to be the best debugging experience that I've ever had, due to the fact that you can visually see where data comes from and flows and you can intercept it at any point to see whats happening.
I also found Max/MSP a dream to do experiment-driven-development and code design and far superior to using the Python and Clojure (the two languages I use most at the moment) REPL's. I think one of the reasons is that while I'm still experimenting with concepts and design/algorithm ideas, I do not need to name things, I can just lay down a few components, connect them and see what happens. In textual languages, everything needs a name, so often you end up with a, b, x etc. I should point out, though, that when I design software (architecture or algorithms), I do it with boxes and lines, so graphical languages may just be a good fit for how I think and I guess not everybody is like that.
Don't even think of keeping things tidy, wires will be everywhere, and the auto-arranger doesn't work well.
With proper software engineering practices, this is not an issue. Without proper software engineering practices, we have the same issues in textual languages.
Modern Tools
This is a very good and important point, but its not inherently a graphical language problem. Things like version control and diffs - sure. They just work in textual languages, but in general, all languages start off with tooling problems. I do believe that good diff tools could be developed for graphical languages and that they would be at least as good as for textual languages and writing a git-compatible file format is obviously possible too (in fact, Max/MSP files look a tiny bit like JSON IIRC). This of course doesn't change the reality that currently there definitely is a tooling problem, so you are very right! But it need not always be that way.
My only complaint about Max/MSP is that I'm one of those people who hates the mouse... I spend most of my days in a keyboard-centric window manager using vim and a keyboard centric web browser, so graphical languages aren't exactly ideal from that point of view.
I've also spent a fair amount of time working in Max/MSP and I would support nearly every statement you said here, even though I'm not a programmer that thinks in graphical terms.
The 'wires going everywhere' thing is potentially a problem, but I usually took it to mean that it was time for more encapsulation or better code organization, which is I think more or less what you were suggesting. On the other hand, lots of artists create amazing work that's so will make you think you're going to have a heart attack just looking at the rats nest. But hey--these are programming amateurs and they're doing amazing things, really fast! I know some musicians who could cook up amazing stuff in Max so fast I would still be thinking about how I would structure the code and they'd be demoing it. It's also important to remember that much of what we focus on as professional programmers is less important to artists for whom cost of implementation is far more important than reuse.
Regarding version control, yes, modern max patches are in fact serialized to disk as JSON. There's an option you can set that causes the program to perform a sort on the structure on save, hopefully minimizing the diff. I worked w/ max patches in git for years, and it was fine though I never really tried to do anything even remotely interesting like merge from another branch; I treated my max patches more like binaries in version control that happened to be stored really efficiently.
In the end, much of the work I would do in Max involved writing a lot of things in C/Java/Javascript and wiring it up, and the reason is, as you alluded to, the mouse. It's just not as productive to move boxes around for me as it is to write text, but boxes and lines make really great glue code for putting together inputs, outputs, and a set of algorithms into a single work, especially if that work is time-related in some way.
these are programming amateurs and they're doing amazing things, really fast!
It's also important to remember that much of what we focus on as professional programmers is less important to artists for whom cost of implementation is far more important than reuse.
These are two things I did not touch on in my comment at all, but you are of course correct and I feel its important enough to mention again. The fact is that people without programming backgrounds are doing amazing things and that they seem to be finding it much easier than with textual languages. The fact is that graphical languages are very successful both in audio (Max/MSP, Reaktor, Synthmaker etc) and graphics (voreen and blender embed a visual language) where they are used successfully by a lot of non-technical people. I've also seen them used in game engines, both for shading/effects/materials and for scripting of game logic[1]. As you mentioned, however, the goals and priorities of these people are generally not the same as those of professional programmers, so often writing once - but quick - is much more important to them than re-usability and modularity and that's perfectly ok if that's what makes sense for them.
boxes and lines make really great glue code for putting together inputs, outputs, and a set of algorithms into a single work
Graphical languages make for fantastic glue code/dependency injection. XML has been traditionally used to externally glue components together and IMHO is often more complex than doing it in the code itself and not really all that much more flexible at the end of the day. Graphical languages are IMHO ideal for this as they show at-a-glance, at a high level, how components in the system are connected, yet still allowing the lower level nitty-gritty algorithms to be managed in a textual language, which may be more optimized for those tasks.
I've done a reasonable amount of programming in Max/MSP and while, again, most code I've seen online was a horrible mess, I attribute that to the fact that these languages usually target non-programmer audiences who, sadly, don't get taught about proper encapsulation, abstraction, naming conventions (ie use actually descriptive names!) and software patterns.
My own code read (to me - though others have commented on it too) almost like something you'd write on a whiteboard to show how the software works to non programmers. I encapsulated each chunk of code that does a single task into its own component, so an individual component (ie diagram) never had more than a few high level "things" connected together, so you can tell - at a glance - what does what. Of course, this means that there are many layers of components, from very high level all the way down to low level, but the point is that with proper encapsulation, visual languages are no harder to understand, read or manage than textual ones and I personally feel that, in many ways, they're actually easier.
I also found debugging Max/MSP code to be the best debugging experience that I've ever had, due to the fact that you can visually see where data comes from and flows and you can intercept it at any point to see whats happening.
I also found Max/MSP a dream to do experiment-driven-development and code design and far superior to using the Python and Clojure (the two languages I use most at the moment) REPL's. I think one of the reasons is that while I'm still experimenting with concepts and design/algorithm ideas, I do not need to name things, I can just lay down a few components, connect them and see what happens. In textual languages, everything needs a name, so often you end up with a, b, x etc. I should point out, though, that when I design software (architecture or algorithms), I do it with boxes and lines, so graphical languages may just be a good fit for how I think and I guess not everybody is like that.
Don't even think of keeping things tidy, wires will be everywhere, and the auto-arranger doesn't work well.
With proper software engineering practices, this is not an issue. Without proper software engineering practices, we have the same issues in textual languages.
Modern Tools
This is a very good and important point, but its not inherently a graphical language problem. Things like version control and diffs - sure. They just work in textual languages, but in general, all languages start off with tooling problems. I do believe that good diff tools could be developed for graphical languages and that they would be at least as good as for textual languages and writing a git-compatible file format is obviously possible too (in fact, Max/MSP files look a tiny bit like JSON IIRC). This of course doesn't change the reality that currently there definitely is a tooling problem, so you are very right! But it need not always be that way.
My only complaint about Max/MSP is that I'm one of those people who hates the mouse... I spend most of my days in a keyboard-centric window manager using vim and a keyboard centric web browser, so graphical languages aren't exactly ideal from that point of view.