Functional languages don't need loops. I'm tempted to say you have the question backwards: loops are somewhat arbitrary; why do imperative languages need them? Imperative languages need loops because they have no other way to write iterative code. Functional languages do: recursion. Recursion is not a "feature" of functional languages, it's a natural consequence of their design. On the other hand, early imperative languages didn't support recursion at all and even modern ones support it poorly, forcing them to use something else to iterate—loops.

One way to look at this is by examining the core of each kind of language. At heart, an imperative program is a set of statements that are executed one after another. Similarly, a functional program is a complex expression made up of functions that's simplified by applying those functions.

If we ask how to iterate in a functional language, the answer is already there: functions or even expressions (in a lazy language) can refer to themselves, giving us unbounded iteration for free. If we ask how to do that with an imperative set of statements, the answer has to be added in—either we have a way of jumping around our set of statements or, since that proves unruly, we have special language constructs expressly designed to iterate. Loops are a purely synthetic solution to the question of iteration: to iterate, we throw in a language construct that says "iterate". A bit of deus ex machina where the language designer, appropriately enough, gets to play god.

Recursion on its own isn't all that functional languages offer. That would be awkward, largely because recursion is too low-level. Not low-level in the sense of direct access to the machine but low-level in the sense of language design and abstraction. Recursion does a poor job of signalling intent. Using recursion everywhere would be confusing because we wouldn't be able to tell, at a glance, what the shape of the iteration is. It's a bit better with a loop: if we have a for-loop, we know that we're taking n steps or iterating over every element of a list; if we have a while loop, we know we're going until we hit some condition. Not much, but recursion doesn't even give us that.

This is where higher-order functions come in. Map, filter, fold and friends package up common recursive patterns into library functions that are easier to use than direct recursion and signal intent. When you see a map, you know that it will apply a function to every element in a list and nothing more. Moreover, when you use map, you know the iteration is going to be correct—you can't make off-by-one errors or skip elements in the list. The same idea holds for all the other higher-order functions available in functional languages' libraries, and there are a lot.

So while recursion is why functional languages don't need a feature specifically for iteration, the real replacement for loops are higher-order functions which just happened to be implemented with recursion internally. These do an even better job of signalling intent than loops because, being library functions rather than language constructs, they can afford to be more narrow and specialized. We're always stuck with the same handful of looping constructs our language gives us, but we can have all the custom, user-supplied, domain-specific higher-order functions we'd like.

Functional languages don't have loops because a combination of recursion and higher-order functions does the same thing but better and more naturally.