The practice. Whether you choose recursion or iteration should depend on the nature of the problem you are trying to solve.
Iteration and recursion are two techniques for dealing with collections of objects. Which one you use depends the nature of the collection. Iteration suits flat collections such as arrays and hash maps; recursion suits nested collections like tree data structures. Note that a collection can be physical, such as tree data structure, or it can be virtual, such as the set of all 4x4 magic squares.
To put it another way, if solving a problem can be done by solving a set of sub-problems of the same kind, then recursion is recommended. If the problem can be solved directly, without breaking it down into nested sub-problems, then iteration is called for.
Sometimes a problem can be solved either way. Here, your choice will depend on professional judgement: How complex is each solution? How difficult (and thus, how defect-prone) is it to code? How efficient is the algorithm? Which of these factors matter more? Say you want to write code to sort the elements of an array. Here are two choices for algorithms:
- Linear insertion sort is a simple iterative solution: an outer loop walks through the array visiting each element to be put in
place; an inner loop slides that element to the correct place in the
(growing) sorted section of the list.
- Quicksort works recursively: it re-arranges the elements of the list to partition them into two sub-lists, the first with all the
elements smaller than a "pivot" value and the second with all
elements larger than the pivot (this is a linear process); then it
calls itself once on each of the two sub-lists to sort them in place.
The linear insertion sort is simple to program and to validate, but has terrible performance for large arrays. Quicksort requires more care to program, but performs well on large arrays.
The theory. Recursion is a more general, and more conceptually powerful, technique than iteration. The theory behind recursion is a little deeper, which means that it takes more effort to "prove" that a recursive algorithm is correct, versus an iterative one. But because of that generality, there are problems that have straight-forward recursive solutions but have no simple iterative solutions.
Think of iteration as a utility knife and recursion as a sword. The sword is more versatile but requires more skill and effort to wield. If you have a Gordian-knot of a problem to solve, the sword is the only thing that will do. But for most problems that you are likely to encounter, the utility knife will get the job done, and get it done faster and easier.
The reality. In many years of working in the so-called real world (i.e., not in academia), I have seen two or three instances of code that recurses, whereas I have probably seen half a gazillion instances of code that iterates.