The rest of the answers are spot-on generally. I would only add that, depending on the context where you need this function, or any function that is "dichotomous" under your perspective (I mean, recursive or not is not always a concern in the majority of calculation cases in the real world, but it seems to matter to you), you may want to actually hide the ...
I'll answer this in Robert C. Martin's words from Clean Code:
The ideal number of arguments for a function is
zero (niladic). Next comes one (monadic), followed
closely by two (dyadic). Three arguments (triadic)
should be avoided where possible. More than three
(polyadic) requires very special justification—and
The client is deciding two things simultaneously in your example:
What to do (add 1)
How to add 1 (recursively or not)
I cannot imagine a case when code like this is not:
Hard to understand and maintain and therefore more prone to bugs
Harder to unittest
The guiding principles here should be separation of concerns:
The caller should invoke a function only with the parameters that are relevant for the result regardless how the calculation is performed;
The called function should provide the result as best suit the needs, whether it's iterative, recursive, cached or a combination of any of these.
Your particular example doesn't make sense to me, but, there are plenty of operations that make sense to run recursively or not.
In particular, you might have a hierarchical structure that is expensive to traverse. When you search this structure or fetch statistics, there may be cases where the caller needs certainty (so you recurse) or approximation ...
Functions are one of our mechanisms for abstraction, and, one aspect of the quality of an abstraction is the usefulness to the consuming programmer, the caller.
Let's try to imagine the caller and since there are two different computations being done, what are the chances that the caller will use a variable for the boolean, rather than always passing a ...