Forth words are not functions and if you try and use them like functions, things will get messy. You should never have things like "a b c d e" in Forth, you should have "abcde," a single word with a descriptive name built from a, b, c, d, and e, and designed so all you have to worry about is the stack effect of "abcde" and not the words it is built on or the data flow. I would say this is like saying C is terrible because people do ridiculous things with macros.

I will give your posts a reread with fresh eyes tomorrow and probably have more to say, it is a bit too much to digest at this hour.

Forth "words" are subroutines. C "functions" are also subroutines. Forth "words" are "not functions" merely because the use of "function" for "subroutine" is terminology specific to certain families of languages (C, Lisp) to which Forth does not belong. This is all irrelevant because I didn't say anything about "functions", just dataflow. My example expression is just as valid in Perl (which calls subroutines "subroutines") or Ruby (which calls them "methods").

A colon definition containing five sequential calls to different words without any control flow or stack manipulation is perfectly unremarkable. Here's a sample word from the F83 block editor, which I am using because F83 is generally accepted as highly competent Forth code, if not exemplary:

    n NEW moves the terminal's cursor to the start of line n,
      and overwrites lines until a line is begun with null input
      ( a Carraige Return).

    : NEW   (S n -- )                                                
       L/SCR SWAP                                                    
       DO   [ FORTH ] I [ EDITOR ] T  EDIT-AT >IN OFF QUERY SPAN @   
         IF  P  ELSE  [ FORTH ] I REDISPLAY  LEAVE  THEN  .SCREEN
       LOOP  .SCREEN  ;                                          

The dataflow in that six-word code sequence is, in C syntax,

    t(i);
    edit_at();
    off(&in);
    query();
    &span ...

With slightly different definitions, this could easily have been, for example,

    edit_at(t(i));
    off(&in);
    span(query()) ...

My point is just that reconstructing the dataflow is a problem you have to solve when you are reading Forth code. The author knew what the dataflow was, presuming it's working code you're looking at. An efficient compiler would have to know, too. But, as the reader, you don't know until you reconstruct it mentally with your global knowledge of the things it's calling. It's an extra error-prone decoding step between the code you're looking at and the semantic understanding you seek.

(I said "without stack manipulation", but stack manipulation generally makes the problem more mentally challenging, not less.)

By contrast, with pop infix syntax, the dataflow is represented locally with the parentheses and commas.

The same thing is true of types in languages with implicit typing (like OCaml and JS), of when call/return pairs follow a conventional stack discipline in Scheme (where the possibility of call/cc exists), of variable capture and escape in languages with closures, of which variables are mutated in languages like Python where all variables are mutable (and to a slightly smaller extent in languages like C, where immutability is possible but not default). The author has this information; the maintainer needs it to successfully modify the program; the compiler would need it to avoid producing grievously inefficient code; and there's no way to express it in the language.

My claim is that, while the optimum may be subjective on this spectrum between implicitness and explicitness, the implicitness itself is objective. You claim to disagree, but to me it sounds like you disagreed simply because you didn't understand what I was trying to express.