The Fibonacci diagram isn't any clearer than the code. The Petri net animation seems as likely to obscure as it is to enlighten.
I think there's space for making better use of graphical environments, and modern IDEs are already stepping up this kind of capability - code folding, mouseover hints, small automatic parameter annotations. I still haven't seen any case for visual programming.
The trick seems to be recognising when this class of tool are applicable and when they aren't. In particular, I've seen some horrific things built in "visual" integration tools that apparently "didn't need developers" but were far more complex than some normal code would have been.
I think much of what makes VP fail at some point is in the details. Programming is often mostly about the details which is why abstractions seem to leak all the time.
When you have think about the details then a denser representation is extremely helpful. Visual Languages don't generally do good at showing enough of the details at once.
Aerodef, automotive, etc all use some form of visual programming. Controls engineers rarely write code, the systems are way too complex. E.g. I highly recommend watching this video from JPL to give you an understanding of where such tools excel. It's about simulating, iterating and then having scientists and engineers autogenerate the code they couldn't possibly write or test
https://www.mathworks.com/products/transitioned/simverificat...
http://www.multibody.net/teaching/msms/students-projects-201...
E.g. cruise control
http://www.cds.caltech.edu/~murray/amwiki/index.php/Cruise_c...
Unreal 4 blueprints I guess :)
For low-level code such as "add two and two together" they are pain. But for expressing "get complex entities, retrieve, mix and match required components, and output a set of complex entities as a result", it's surprisingly good. If used correctly :)
Disclaimer: only judging from Youtube videos and tutorials