> Can't really do that as easily in APL.

This doesn't match my experience at all. I present you part of a formal language over an AST, no cover functions in sight:

    p⍪←i ⋄ t k n pos end(⊣⍪I)←⊂i            ⍝ node insertion
    i←i[⍋p[i←⍸(t[p]=Z)∧p≠⍳≢p]]              ⍝ select sibling groups
    msk←~t[p]∊F G T ⋄ rz←p I@{msk[⍵]}⍣≡⍳≢p  ⍝ associate lexical boundaries
    (n∊-sym⍳,¨'⎕⍞')∧(≠p)<{⍵∨⍵[p]}⍣≡(t∊E B)  ⍝ find expressions tainted by user input

In fact, when you see the above in real code, they are all variations on the theme, tailored to the specific needs of the immediate sub-problem. As library functions, such needs tend to accrete functions and function parameters into our library methods over time, making them harder to understand and visually noisier in the code.

To my eyes, the crux is that our formal language is _discovered_ not handed down from God. As I'm sure you're excruciatingly aware, that discovery process means we benefit from the flexibility to quickly iterate on the _entire architecture_ of our code, otherwise we end up with baked-in obsolete assumptions and the corresponding piles of workarounds.

In my experience, the Iversonian languages provide architectural expressability and iterability _par excellence_.

[0]:https://github.com/Co-dfns/Co-dfns/tree/master