Earlier quoted context omitted.
> (x + y) is going to be an expression in almost any language... But the equivalent for loop is not.
It is wherever '+'/(equivalent function) overloading is a thing - C++, Haskell, Rust, etc. There isn't even a good reason to think of it as a loop, because for different types it may not be a loop at all.
> "(x + y) is an expression rather than a statement".
The point isn't that (x + y) wouldn't be a statement in other languages, rather than point is that in languages the reader of the article is most likely to be familiar with, you would use a for loop to solve the problem, and obviously a for loop is a statement, not an expression. You can't compose statements as you can expressions. That was the only point the article was making there.
You clearly missed it, because you went on saying that (x + y) is an expression in almost any language, which while true, is irrelevant for languages where (x + y) isn't the way you would express the operation in question. Which, by the way, includes idiomatic C++, Haskell, and Rust, in all of which overloading (+) to do something so specific would at best be seen in a purpose-specific library (like numpy) only, but isn't automatically present in the language. That means it doesn't force you to think in that way, which J does, which is the point the article is making.
In most languages that most programmers use, for loops are common, and if all of those are replaced by expressions, you get a more expressive language (for dealing with arrays). That's the point that the article is making, and you haven't addressed it at all.