One thing that your examples tend to have in common is that they deal with describing states (documents), not modelling processes. Maybe that has something to do with it. Describing actions ends up effectively requiring flowcharts, which is what visual programming typically ends up being, and that gets painful and slow tremendously quickly. That's why visual programming tools do not endure: because once you get skilled enough, you will find them annoyingly constrained.
I can just point out that my niche (accounting) is arguably one of the oldest in computing. Visual programming to address accounting challenges has been tried over, and over, and over, and it failed. every. single. time. It's a massive target that everyone hopes to hit, because the jackpot is massive, but I would argue that it will never happen. Excel keeps winning because it doesn't even try to play that game: if you want to do anything beyond instant calculation, it gives you VBA and off you go. That's what people really want: if they are smart enough to want advanced process modelling, they are smart enough to learn how to write an "if" block.
> it is difficult to get a man to understand something when his salary depends on his not understanding it.
Believe me, there is also a large industry of programmers invested in visual paradigms; and their salary depends directly on not understanding the lessons of the past.