Of course, that's one way to look at it, and a valid one. Most of the time I do too, but I can accept some degree if implicit behaviour if it's consistent and (conceptually) simple enough.
> the amount of overloaded meaning of existing operators
But this is not true in regards to J. In J and other array-based languages the number of overloaded meanings for operators is actually less than in "normal" languages. That's because in J all the operators work on arrays and only on arrays. No operator ever deals with things other than arrays, and in basic J there's just one thing other than array anyway (a box).
In Python this:
2 + 2
and this:
[1, 2, 3] + [1, 2, 3]
are two different operators, but in J (ignore syntactic differences) this:
2 + 2
and this:
1 2 3 + 1 2 3 NB. resulting in 2 4 6
are both applications of the same operator.
There is a certain appeal to languages built on "turtles all the way down" principle - one of the benefits is that they tend to be compact, simple and consistent. On the other hand, when you're not dealing with turtles, they tend to be irritating at best and completely unusable at worst.
Anyway, I'm not trying to convince you to adopt J right now and start using it for writing web apps, I just want to say there are some interesting concepts in J which, while being unfamiliar, are not necessarily worse than the things we're used to. And they're not useless either: a week of learning J made my NumPy code much better, for example.
Not so.
I only need to write down 2 lines of code: one line for the for-loop, and one line for the actual instruction(s).
Personally, I prefer explicitness instead of increasing the amount of overloaded meaning of existing operators.