I consider myself an algorithm/data-structure rookie. But from the places where I have used recursion over iteration I can say that its purpose is always to reduce code length. The sole purpose for me to use a recursive function is to make program efficient and code cleaner. It has its dis-advantages, I agree.

Now coming to iteration vs recursion, it would have been great if it were up to us to elect one. Becuase if you see, javascript engines are optimised to run iteration efficiently over recursion. So its faster to use a for loop than recursion. This is not the case with other programming languages. But as I use javascript heavily, it is a matter of concern for me.

In languages like C and C++, the program's efficency is directly proportional to the code complexity. So you may write easy to read code and there will always be room to improve it through methods like recursion.

First of all, it's important to know what kind of problem you have. Most of the time, things like memory constraints and execution time don't even matter, so you should focus on what you can type quickly and feel comfortable doing. Everything else is premature optimization and will kill your capacity and burn through your project's money.

If you, however, know that whatever you are writing might have a big impact, because it will iterate infinitely (or at least a lot of times), it's important to know your compiler/interpreter. Because if they don't do things like tail call optimization, you will run into a stack overflow easily. Many modern languages support this feature, but you should be careful and make sure anyway.

I think i'd go with iterative, not because it's better or anything like that but purely because it's easier to understand by other developers who might be on my team now or in the future.

But it also depends on the problem. For example iterating through the DOM (deconstructing or constructing) requires recursion in order to access the nth set of children and their attributes. Thinking about it, I guess a purely iterative approach could be used but it would be overly complicated and the code would be needlessly long when compared with the recursive method.

So whilst it's important to consider the technical procs/cons of each I would suggest that the most important is what the team are most comfortable with as well as what the problem requires in order to present an effective solution.

To add more about

Avoid heap memory allocation

It also helps to know your language/compiler: if it supports tail call optimization, then you can do recursive call and avoid the memory footprint you would usually get from many recursive calls

Some of the rules are silly to apply outside of the context where they were invented. For example

Avoid heap memory allocation

That makes sense if you need extreme reliability, have serious hardware constraints and ten times the budget other organizations have.

But if you're just creating a webpage or data analysis script or even for 95% of server code (usually performance is determined by 5%), you're just going to spend a lot of extra time to save the computer some seconds.

I'm also not convinced that recursion is inherently complicated, I think it has more to do with what we're used to. I've also seen some needlessly complicated code to traverse trees, written by people scared of recursion.