The thing I think the spaghetti visual graphs get wrong is a lack of adherence to the structured programming theorem. Most data flows are mostly linear/sequential, and DAGs - which also can be expressed linearly as "send/jump ahead but not backwards", cover most of the rest. Complex structures that need to describe comprehensive fanin/fanout/feedback functionality are exceptions, and as with uses of "goto" in structured languages, most can be reduced to an implementation detail of a single node. So presenting all the options on every node, every time, with cable wiring going everywhere, is a very cluttered syntax for something that could usually be a "Lego brick" expression.
The beauty of stack languages is shared with that of RPN calculators and their postfix syntax model: You can enter the expression very quickly and precisely. Parens and operators don't "get in the way". Names aren't needed for temporary values. Small modifications don't require a rewrite. They feel mostly linear when "in their wheelhouse."
Where postfix starts losing to prefix and infix is when you have something that requires a lot of scanning back and forth to determine state. Function arguments lack clarity. Stack underflow becomes a real failure case. The scaling in terms of readability isn't very good, so "don't write large words" becomes an imperative when it's a generalized programming syntax as in Forth.
The language I'm working on right now currently uses RPN for single-line, compile-time expressions, while runtime evaluation is vertical and operates entirely in terms of keyword prefix + memory addresses, like an assembler. This constrains the scope in two ways, giving it a "twice linear" feel since left-to-right is the compile-time world while top-to-bottom is the runtime world, and those worlds only really cross over in terms of referring to compile-time identifiers(e.g. label and variable declarations, type evaluation). Since left to right is all compile-time, the meaning of an expression can vary a lot depending on the keyword, and so to expand the language I also have the option of adding original single-line DSLs to target specific runtime expressions, if I can't get what I want by adding more types to the RPN system. This is intended for small inline programs called from scripting so the at-scale view of composability isn't the main priority. It's still early, though, so I'll see how that all works out in practice.