It becomes intuitive. APL primitives are particular instantiations of clean high-level concepts. While a C programmer would think "I'll make a sparse encoding of this boolean array" a K programmer would just write Where. Having a rigorous definition for a pattern like this is a nice guide for the intuition, but it's possible to get in a situation where what you want to do and what the language provides don't line up. And there are domains like graph algorithms that largely don't fit into an array style. For these you'd have to fall back to writing scalar-style code.

There's not much of a custom DSL problem, because APL/K emphasize using the primitives that are built in, and user-defined functions will have names not symbols. Some codebases will be a challenge to read because these languages tend to attract programmers who write things their own way, and for K in particular many users—the inventor Arthur Whitney most of all—don't like to write long explanations of how their code works. The OP, while well explained, is pretty advanced material. Knowing a lot about array programming makes the high-level picture clear but I would say many of the code examples would take some effort for even a good array programmer to understand.