I don't think this is the most common--even when you have side-effects, most loops are conceptually going over some collection. Python takes this to an extreme with its for...in loop which is just an ugly map, but it's true in most languages.
Just because you have side-effects does not mean you can't express your computation more neatly using a higher-order function. And some of the imperative uses of a loop are easy to abstract into a higher-order function as well: while (true) {...} becomes forever, for example.
map is a pretty bad example in python due to it being eager while for can be made lazy with yielding instead of returning. Further, list comprehensions and generator expressions tend to be (at least in my experience) fewer characters than map/filter. To get lazy map/filter you need to go out of the core into itertools.
All of that sounds like faults of Python, particularly with its horrible lambda syntax. (E.g. 'map (+ 2) list' is much easier to read than a list comprehension.) Besides, I am not sure why you couldn't generalize map to lazy structures the same way you do with for--Python might not do that, but that is again Python's fault.
Conceptually, a for...in loop is basically like a map, except that it doesn't return a list. Of course, this is yet another fault of Python with an arbitrary separation of statements and expressions. If the for...in loop was just an expression--and that's basically what a list comprehension is, if you squint--it would probably be exactly like map.
My real point was that the only way to get C-style for-loop behavior in Python is to do for i in range(a,b), which is basically equivalent to map fn [1..10].
Just because you have side-effects does not mean you can't express your computation more neatly using a higher-order function. And some of the imperative uses of a loop are easy to abstract into a higher-order function as well: while (true) {...} becomes forever, for example.