How could you look at an APL-family language and then be totally outraged that the implementation took quite a bit stylistically from the language itself?
Conventional C style is there to improve its readability and maintainability. Applying APL style to C code is sort of like trying to use Russian grammar with English vocabulary, you might be able to puzzle out the meaning, but it is a stupid waste of time.
Actually, given that a substantial part of the codebase involves looping simple operators over vectors, it makes sense to use macros to make the looping implicit.
Code like this needs to be read more slowly than usual, because unlike much C code, the information level isn't low enough that you can read it lines at a time. Math papers have all these weird sigma symbols and stuff, too; you can't read just them as fast as you would read "for (i=0; i<N; i++) {" for the millionth time.
Likewise, rather than writing "for (i=0; i<N; i++) {" yet again, K just calls that ' and moves on. In the source, there's a macro called DO, which is used extensively. DO(N, Blk) -> for(i=0, int _n=N; i<_n; i++) { Blk } . The APLs are about having a notation that doesn't constantly get in the way of thinking about your actual problem.
In practical implementations we call this code write-only.
It's funny that you bring up mathematical notation because mathematical notation is completely optimized for write-only. Mathematics is so obsessed with one letter variable names that they had to gather letters from other alphabets to continue their opaque tradition.
I find mathematical notation to be very read-friendly. Reading a paper from an unfamiliar field can be tough, as knowledge of the standard notation is typically assumed (as is the case when reading code from an unfamiliar programming language).
Mathematical "code" isn't usually meant to be read without the surrounding variable and notation declarations, for example "Let x be ..." or "where • is the ... operation". If those are provided, short variable names and terse notation allow for the intent to be presented clearly, without it being obscured by line-length restrictions and a limited number of generic constructs (eg. for-loops instead of the summation operator).
That said, I'm finding this C implementation of J to be pretty cryptic. Of course, that's no reason to dismiss the J programming language itself.