I look at that and I see a couple of things. First, this is procedural programming straight out of my old, old COBOL books. Batch processing - read some files, process the data, output it. That graph is pretty, but no different from the structured analysis and design that was forced on me in the mid 80s.
That stuff was a nightmare to work with. No real search, endless 2D layout issues, no way to reuse, a very little bit of information conveyed in a lot of space, no way to debug, and so on. And, if your program is anything but batch/data flow oriented, good luck.
I see maybe 100-300 lines of JSON in the image. Or Lua. Whatever. A modest amount of paste code to tie already written components together in in/out chains. Now, I get that your diagram is more easily 'groked' than JSON, and that is a benefit. But what if I want to search for things? Use awesome tools like sed to batch change stuff? Perform static analysis? All that graphical stuff just falls apart. Oh, perhaps there is some DOM, and I access that, but then I'm right back into the incredible power and expressiveness of text.
More importantly, I'd like to see the flow diagrams of all those nodes you are connecting together. I am prepared for egg on my face here, but are those written in NoFlo, or text? I'm guessing the latter.
So, how is this different than LabView? I completely understand the value of being able to quickly plug together pre-existing components when you have a tiny interface (you just have in/out nodes, basically, in that diagram). A small solution for a small problem, and I don't mean that dismissively.
Despite the article's claim, and as many have already said, this stuff has been around for decades. There are definitely places for it. But having lived through it, I tell you SA/SD died a very deserved death.
Sorry, this isn't directed at you, you were just the person kind enough to provide an asked for example.
The other major thing that sticks out for me is that that graph is just a high level, block diagram of the program. Well, "just" not meant to be dismissive. The original article talks about the horrors of programming where changing one thing means changing 10 other components. They are not describing programming, they are describing hacking spaghetti code with no design. If that is the way you program, or the way the code base you are working on is coded, then I can see why these flow diagrams seem so revolutionary - a design is being done, and software is broken up into discrete components. That's pretty fundamental SW engineering. But the magic is not in the 2D visual display, but in the idea of small components that do one thing and that are not intimately tied to other components. So hey, if the tool helps you learn or use that method, good, I guess. How you reasonably scale it up to anything large is beyond me (I've done entire avionics systems in data flow diagrams, and it ain't pretty at that scale, believe me).