Hello from APL! (And also Haskell, to a smaller extent.)
I bet all these languages come from people with a thick CS theory background, and thus a tradition and a need to write formulae on a blackboard.
Unlike a keyboard, a blackboard is a graphical device, it's slow to produce long character strings, but basically any one glyph takes about the same time to write, be it an x, ≡, ∉, ⊕, ℵ, etc.
Then you want to plainly represent the same concepts in the computer language, et voilà.
Yes, blackboard-simple is not the same as keyboard-simple. Unless the language is specifically for code-golfing, such design choices suggest the creators haven't thought very holistically about their product.
(I think we got off the rails a bit: the linked article looks to be ASCII-only! But I feel the need to defend myself...)
This is a bit of a change-up from the usual "write-only language" complaint! But it does have the benefit of accuracy: yes, if you know the language, the time savings in writing APL are smaller than the savings in reading it. Both are faster, once you've spent a week or two with the keyboard, since even the slow method of typing a prefix character followed by a letter is faster than typing out a keyword in another language.
Array languages are rarely "product"s. While I do offer it to others for free, I make the language I want to use, and having nice-to-read symbols for a one-time tooling cost is a nice convenience for me. Don't call me thoughtless for having different tradeoffs than you!
They likely wanted something out, and wanted something to write a number of papers about. Unifying the computer language syntax and the familiar CS theory syntax may be a shrewd product decision, if, again, producing papers and obtaining doctorates is the goal, while industry acceptance is a distant secondary consideration.
Or... it's a conscious design choice that you happen to disagree with. Just because you can think of one disadvantage of the approach, doesn't mean that the creators are idiot who didn't think about what they were doing.
I tried using search engines to find whether the fold function in Joy, a vastly better-known language, takes an initial element or not. Best I got, after some fiddling with search terms, was a Joy tutorial that did have an example of fold. Certainly much slower than using language documentation. Yes, this choice will prevent F from being the next Elixir or Kotlin, but it's hardly relevant to the usability of a niche language like this.
> In F, everything is a function from triples of (environment;stack;queue) to triples of (environment;stack;queue).
I dabble with compiler-writing, and one of the techniques there is to program an abstract machine. It fills a nice niche - it's a bit more concrete than hacking together an interpreter over your AST, and a lot less concrete than writing out LLVM instructions.
Some examples are Krivine machines and SECD machines (which stands for Stack, Environment, Control, Dump).
They let you play around with ideas before you commit to a particular semantics of your language, for instance, whether you'll pass by value or reference, via the stack, or via the heap.
But exposing (e;s;q) directly to the programmer is a fascinating idea! If I'm thinking about it right, it means a programmer could write code to take a parameter which was passed in via the stack, and decide "No I think this should be on the heap instead" and then update all pointers in the program accordingly.
In the "simple and interesting language" front we also recently got a post about Forsp, a hybrid between a lisp and Forth: https://github.com/xorvoid/forsp
Take an axe to the troubleshoot-ability of your language with this one weird trick that makes it impossible to google.