That's a very reductive and bad-faith interpretation of the criticism. A much better one would be: "You can write either write a symbol soup with multiple paragraphs explaining what the soup does and why it is good, or you could write an equivalent amount of code in a verbose, readable language. The former option introduces two places for errors: they could be either in the code, or in the mapping from the code to the prose, while the latter only has one."
Symbol soup is just fine when you're working in a highly restricted domain with limited scope for novel abstractions - which may well suit the idiomatic usage of array languages. Math expressions are symbol soup, but a trained mathematician can read them quite directly.
Math expressions and notations are far more expressive than APL or J, because they are graphical, highly flexible, and not meant to be compiled. They also tend to be accompanied by text for whatever cannot be efficiently conveyed by the notation.
This is an argument which has been going on for years; "crazy paragraphs because the code is ugly" is a thoughtless low effort criticism and it doesn't deserve a steelman fleshed out rebuttal if the person hasn't put any effort in.
You say "a symbol soup with multiple paragraphs explaining what the soup does and why it is good" - honestly, do you think people write multiple paragraphs explaining the code to beginners who can't read APL every single time they write any APL? Of course they don't! Your proposal relies on "symbol soup" being a fair and accurate description, which it isn't.
And, are you suggesting that people don't write comments explaining their code in common popular languages? Of course they do! (and should)
And, are you suggesting that people don't have to learn and practise to be able to read common popular languages when they learn to program? Of course they do, look at posts around the internet on people learning Java and Rust and C# and C++ and Python asking what some code means, what some syntax means, and not only beginners, lots of people ask like "I can code but what is this syntax?" and it's a Python generator comprehension, or a ternary operator, or a C# LINQ SQL style or a pattern match or an anonymous function or a compiler hint or a documentation generator template or a generic type or a turbofish or whatever thing they hadn't seen before in their previous languages or codebases.
And, are you suggesting that comments getting out of sync with code is only a problem in array languages? Of course it isn't.
Or that nobody ever complains about the readability of Java because it's so verbose and has so much abstraction you can't see what's supposed to be happening? People do. I do.
And as always, what about regex? It's so useful as a text processing language that it's often still shorter and cleaner to write a complex regex and paragraphs of comments explaining it, than to code the equivalent in classic string indexing and slicing and if/else branches. You'd end up writing a Greenspun-esque ad hoc, informally-specified, bug-ridden, slow implementation of half a regex engine.
That's not to say there is no criticism of APL's style possible, but if you want people to take the criticism seriously, have something new to say about it or some solid support and explanation for it. "Whenever you look at a problem somebody’s been working on for a week or a month or maybe years and propose a simple, obvious solution that just happens to be the first thing that comes into your head, then you’re also making it crystal clear to people what you think of them and their work." - https://exple.tive.org/blarg/2019/04/17/why-dont-you-just/
