Allowing the same statement to do any kind of arbitrary nonsense is not the good kind of expressiveness. Far better to separate your concerns, and keep the orthogonal parts orthogonal. C-style for mixes too many different things.
Semantics of the C-style for loop are pretty well defined - it's: for(initialize form ; condition form ; step form) { loop body forms }. Ascribing any different meaning to it, like e.g. that all three forms in the loop header must be present or must refer to the same set of variables, is a mistake.
That said, if one has an alternative that can express their intention better (like e.g. mapcar, foreach loop, Lisp's dotimes, etc.), one should use it instead.
I disagree - debugging costs usually come directly from choosing a construct that does not express programmer's intentions (like using a naked for when foreach would be more adequate - or, conversely, by messing with conditionals inside loop body when putting the condition in the loop header would be more adequate).
Debugging a higher order function application is harder than stepping through a loop, at least in most debuggers I've used. I use them only when the logic called indirectly is not complicated to require much debugging (and I still wind up converting comprehensions into loops because they are too much trouble).
What you call "Arbitrary nonsense" is for others good practice. For loops allow you to check all the conditions of the loop in one single line, without having to read the body of the loop, which i consider good practice.
I'd say fair, but...
> indeed try to avoid languages where "for" allows such arbitrary constructs.
... come on. I'd say - go for such languages, they give you if a tiny bit more expressive power than ones who don't let you write such a loop.