One of the things that annoys me most is when people suggest that the power of array-oriented programming is in having a boatload of built-in array processing functions with short names. As noted in the article, that kind of thing is simple to build as a library in most languages. There is a deeper thing, built into the semantics itself -- the way operators are automatically generalized to work on arbitrarily high-dimensional arrays, which can be manipulated by the programmer. Append (`,` in J) isn't just for tacking a vector onto a vector. It's also for sticking an extra element onto every row of a matrix (or every column), or for tacking the rows of two matrices together (or their columns), extending a rectuangular prism with a new plane (along which dimension? whichever you want!)... I'd talk about 4-, 5-dimensional, and higher if we had convenient prose terms for them. All this is from manipulating how the append function gets lifted to multi-dimensional structures. Or maybe you want to just add a matrix and a vector... do you want to treat the vector as a row or as a column? How about getting an outer product? Operate on the entirety of one argument and individual cells of the other, still just by manipulating how lifting is done. If you haven't been messing with verbs' ranks, you've only had a superficial look at array-oriented programming.

This kind of flexibility is not specific to the functions that come in the standard library. It's part of the language semantics, so it applies to every function the programmer writes. That's a fair bit harder to package up as a library (I've done it in Racket by more or less temporarily redefining function application), so I tend to be dubious of claims to have brought this paradigm into another language. Array-oriented programming is not just a combinator library.