Actually you have it backwards, probably because you confused J's somewhat cryptic notation as the only way to implement the same concept.
It's the for loops, with their sprawl of non-declarative code, that would be equivalent to the regex opaqueness, and a well named operator or function to achieve the same thing that would be more like J.
E.g. would you rather use a:
sort(myList, order=desc)
Similarly, think of operations like:
findElement(myList, predicate)
filterElements(myList, predicate)
keepElements(myList, predicate)
forEach(myList, myFunc)
forEachParallel(myList, myFunc, chunks=5)
If 10-20 such language provided functions covered all cases, I'd use them over for loops all the time. In fact that's how people use e.g. lodash.
What J adds is a succinct syntax to write and compose such primitives at the language level.
But such a syntax is not necessary to achieve the same concept (although not the same brevity/expressiveness) and be better/more readable than for loops...
P.S And regexes themselves should be compared to the equivalent parsing code -- which could require a FSM, or an ad-hoc buggy implementation of the same checks/captures spanning 10s or 100s of lines depending on the regex. Except if you just use a regex for very simple things where e.g. a "contains" function or some splitting etc will be simpler.