I know of very few programmers who still flow-chart (except in PowerPoint slides for managers and other non-technical types)- most sketch code in either C or pseudocode.
Far more important these days is showing object relationships, using UML or similar notations.
I personally think they are complementary to each other; you'd be surprised at how many bugs (and hidden "gotchas") you can find when first flowcharting a process, before implementing it in any form of code (pseudo or otherwise). Object diagrams, UML, and the like are useful (and necessary for complex systems), but they don't tell the whole story. The only place with flowcharting become difficult (but there are ways that have evolved from Six Sigma) is in documenting parallel flows; it becomes complicated, but doable.
You're aware that it turns the flowchart directly into code, right ? and that 99% of arduino users are not professional programmes ?
Unfortunately, some might become professional programmers, and might carry over bad habits (or have trouble understanding existing paradigms) should they try to make the transition towards professional programming. See BASIC and GOTO, for example...
I've said that I am a noob but if some PCAs come with this kind of programming interface then it means that it does make some sense
This is where your making a mistake; you claim to be a n00b, while postulating on topics that you haven't got the experience to postulate on. Simply because it seems to be something that is used all over the place, doesn't make it the correct solution, or even the best solution. Inertia is a powerful thing; look at politics...
;D