In my engineering days I used a flow chart style development language for SCADA systems. It was the only way to program the damn thing so you figured it out. It was not an easy to read format. Graphics is always going to be harder than text.
In more recent years I've had various interactions with graphical languages for robotics. FIRST LEGO League (elementary school) uses Mindstorms software and the kids *hated* it (so did I). To get the details you have to click on the block and sometimes multiple clicks to get the details of what's going on. The printouts were worthless. Teams that actually figured out how to do sub-blocks win awards for something so standard in OO programming.
In FIRST Robotics Competition (high school) we have the option of Java, C++, and LabView (a graphical flow chart style environment), and some other non-supported languages (meaning you use them you're on your own - don't ask FRC for help). I've not used LabView but I can only think of a handful of teams I've talked to that actually use it. It's hard to understand what's going, the details require clicking through objects and viewing their properties. Teams struggle mightily with it unless a mentor uses it for work. Most go with Java because their high schools are teaching it and it's easy to understand and the built-in Robot Builder gets you 85% of the way there to a working program (and finding mentors for it isn't that tough).
To put it in perspective in a 15 second autonomous period you get big points, literally for just driving 4 feet forward but yet I'd say 75% of all teams don't do it. I would bet the a good chunk of those teams are using LabView and struggle to figure out even the basics of autonomous robot programming but it 'looks' easy because it's graphical. In Java and C++ this is a couple lines of code that can be done by setting the motor outputs manually to some value and resetting them to zero after a certain length of time, or if you have encoders on your motors, a certain distance has been traveled. Of course some of these struggles can be laid at the feet of not reading the fine manuals that come along with the control system. These are high school kids after all.
If it makes sense for your users then I'd give it a qualified 'maybe'. Looping and complex decision branches is where the graphical languages get ugly real fast. But for very simple stuff it's not bad but 'simple' is the keyword. Simple works for examples but real-world applications tend to get complicated and complex and then it's worse, IMO, than text based languages. Anyway, that's been my experience.