In a world with maps and folds do new languages really need for-loops? They seem like putting goto into a language as a fallback for uncommon performance cases and people who don't have the hang of higher order functions.
In particular, I don't like the fact the for-loops are often used in first examples. I had that issue when I looked at tutorials for D and Go for the first time. My initial reaction was "Seriously?"
Loops have their place: in imperative languages, they allow you to very naturally express a series of instructions, which are of course what imperative languages are meant to express in the first place. By the same token, loops aren't really of much use in functional languages, if they're supported at all, unless the language also supports destructive update (and therefore has imperative features). One can debate the merits of imperative vs. functional programming, but there's no reason to avoid for-loops as a natural expression within the imperative paradigm.
One thing I like about python loops, which CoffeeScript and Ruby, and apparently Nimrod, have adopted as well, is that they make you iterate over a data structure, rather than the C-style of providing start, finish, and step. Iterating over a data structure provides a better guarantee that the loop will terminate without errors (whereas, in Java for example, you could fall off the end of a linked list or an array if you're not careful about your ending test or update step). This ends up being conceptually similar to a map, which is how Ruby's each method works anyway.
I don't know about D, but I don't think Go has map and other functional combinators, due to lack of generics. Besides, the world has had map and fold for a long time now, and this has not prevented for loops and iterators.
In particular, I don't like the fact the for-loops are often used in first examples. I had that issue when I looked at tutorials for D and Go for the first time. My initial reaction was "Seriously?"