The answer to your question is: money
Code exists as a way for humans to talk with the computer in a way in which the computer understands what actions to take in what circumstances. Each generation away makes code easier for humans to read and use and (generally) more expensive and specific to implement. Adding a visual layer on top of this is another expense.
It has been done. It will be done again. Most likely very specifically and probably quite badly. A lot of programs can be introduced when putting another layer between the programmer and the machine. webMethods is a good example of what not to do. CA Workflow is another.
Coding with a 2GL or 3GL or 4GL directly in text is currently the most efficient method for achieving the desired results. Existing systems do the job well enough. New systems are expensive.
In many cases it is a 'build it and they will come'. Quite a few attempts have been made to make GUI programming language interfaces; in particular for workflow applications. It gets messy quite quickly. Take a program which has 900 lines of actual code (disregard comments, headings, etc, just the raw code). Translate that into a diagram and then try to debug it. Print out out? On what? an A0 printer?
Visualise a program with 100 calls in the main. How would this be represented on the screen? Would each call open up in its own screen? Would you spend your time scrolling around looking for bits and pieces?
Have a read of https://en.wikipedia.org/wiki/...
If you want a practical idea of why it is not feasible then have a look at some of the existing examples of visual front end for code generation.
I have used a CASE tool to create a system for a project. The first month was not too bad. After a while traversing through the screens can really get to you. I found that many people had printed copies of what the program had so they did not lose track of where they were. Humans can only hold so much in their mind at any one time. At the end of the project the system would not 'balance' and finding the 'bugs' was an absolute nightmare, one which involved using the existing solution as a basis and redoing the whole thing from scratch from the bottom up. If this happened in the corporate world the tool would be out the window very shortly.
As another example, I have used a Workflow tool which had a graphical interface to define the rules for the workflow engine. Great. Except when it didn't work. Or did something in the output which did not match the graphical interface. Or where it just plain did not match up. In the end I ran SQL queries on the database to the rules table to write the rules I needed.
Another example of using a graphical method for programming instead of text is Atlassian who removed wiki markup from their flagship product Confluence. This resulted in a huge backlash in the corporate wiki arena with many still bitter over the loss of the ability to write code in text. Atlassian have since somewhat recanted and users can now enter code as xml markup. It is a good case showing that the flexibility of code can not be easily replaced by a gui.