It fails in other areas because code is remarkably info-dense, and if you split that out into individual components, it takes a huge amount of screen space and visual manipulation for even simple subroutines. I encourage you to take a simple function and draw out the parse tree for it. It's surprisingly large, with lots of different node types all strung together in unusual ways. Think about how much people complain about the parentheses in Lisp; now imagine that each set of parentheses is a box on screen.
When software construction is finally "solved", visual representations and interfaces will be common. Our current mechanisms are simply too crude, lacking sufficient methods of abstraction, to work well. In fact, they do the opposite and point out what deep flaws exist in the current state of the art.
For that matter, Lisp is not programming; it's specifying a dataset. Except, well, it actually is programming, because you can execute that dataset. When you push it far enough, the distinction between code and data disappears.
This is probably an indication that software construction will never be "solved": once an acceptable representation has been found for one level of complexity, someone will quickly build on that and take it to the next level of complexity, and then the abstractions will once again prove inadequate.
To me, HTML, CSS, XML, etc. are not code and do not have real bugs; they have design flaws and syntax flaws, just as a picture may need more red or blue. (But note that I'm not sure there's a right answer here, and I certainly respect you and your opinion.)
I also think that it's not about abstractions but better abstraction mechanisms which work to reduce complexity at any level. It may get more complex, but you can manage that complexity much more skillfully. I am absolutely confident that we can find better abstraction mechanisms.
GUI layout in the sense of creating a series of instructions for a computer to automatically create and display the same image is much closer to programming than you're making it out to be. In fact, I would say that it is programming at a higher level, as you're not producing an image - you're producing code that tells the computer how to produce that image. If that's not programming, I don't know what is.
There is quite a lot of research going on with visual programming, but the return on effort in most cases is most discouraging.
A second reason is that higher level languages for mechanical design hasn't been successful. my guess it's because mechanical objects are very cost sensitive, so people use low level tools, similar to embedded developers using c+asm.
On the other hand , if you look at fpga and chip design , where complexity has exploded and transistors price really plummeted , you see a move to higher and higher level textual languages, from the schematic systems used in the past.
Another interesting use case for visual languages is visual domain specific languages. metacase has some success with this. my guess is that visual languages can be much easier for domain experts to use and understand, in some cases.
How do you create an intuitive, visual representation of recursion? Iteration over an array? The task isn't creating a visual representation of current programming paradigms, it's creating a whole new conceptual approach. I'm not sure that such a thing is even possible.
[1] http://imranontech.com/2007/01/24/using-fizzbuzz-to-find-dev...
Edit: There is also Agilent VEE.
Anyway, I think a framework that includes a web-based data handling thing might be a success.
In contrast, every natural language that I've seen, along with every remotely successful programming language, uses a one dimensional sequence of words and/or symbols with an implicit grammatical structure. That is probably no coincidence.