I agree that human understanding of software is one of the primary bottlenecks and difficulties of writing and maintaining software, but it's always a little suspect when someone claims to improve something about programming and then talks about hypothetical toy algorithms like making lunch.

The rules proposed for creating easily legible diagrams determine mathematical limits for the proposed visual language. (Prime example: no crossing of arrows.)

That's fine, but I think what I would find more convincing is an example of actual complicated program mocked up in this manner. I'm all for using toy examples to sketch out the basics, but if you're proposing a system to make software systems easier to understand, you should probably demonstrate it actually makes at least one software system easier to understand.

I tried to do this with a JS library: http://glench.github.io/fuzzyset.js/ui/

It looks like since this paper the author(s?) have developed it further and built some real stuff. Here's a screenshot on their website: http://drakon-editor.sourceforge.net/folder-parrot.png

Is this an easier representation to read and understand? I'm not so sure.

That folder-parrot example doesn't seem to illustrate the DRAKON methodology very well. The flow breaks when you have to read the code within each step.

Couple more links:

https://en.m.wikipedia.org/wiki/DRAKON

https://drakonhub.com

Nice set of rules for laying out flowcharts. That said there's a reason flowcharts are passé as a form of documentation.