I agree. But I also think they ~fail~ don't fulfil their potential in other regards.

• They fail at visual communication. Some visualize data types (common in block-based). Some visualize complex control flow (common in node-wire). Some visualize runtime state (common in state charts). Few give the programmer any choice in the matter. None (that I've seen) let the programmer build their own visual affordances in the editing environment. None meaningfully use animation.
• They fail at interactive communication. Some are structural, preventing invalid program configurations (blocks). Some use interaction as part of the programming process (PbD/PbE). Some use tight cycles that approach the sensation of dialectic (fast TDD). None give you the flexibility to define what interaction ought to mean as part of the activity of programming (though some GPT experiments are verging on this). None meaningfully use theatre.

It's easier to make a mediocre textual programming language than it is to make a mediocre visual one. I imagine the same would be true if one wanted to make a good visual programming tool — but I don't think anyone has done that yet, so I can't say for certain :)

Your reply just planted the idea that we might need to figure out consciousness to figure out how to create a truly good visual programming language. Somehow our brains are able to blend visual and symbolic thinking into one coherent model, but how that's pulled off remains a mystery.

I think it's easy to come up with a long list of concrete things programming tools (visual or not) could do better. It's just prohibitively effortful to do the design, implementation, etc. work needed to realize those ideas.

So while you might be right in the limit, let's not preclude the possibility of making progress in the meantime.

I want a spoken language based on the potent succinctness of an APL