No. You can't easily avoid recursion for the merge-append case, since that has to descend to multiple children.
Agreed. That's why it's not in the while loop in my sketch of the suggested rework.
TBH I dislike the fact that you did the subquery case randomly differently from the existing cases; it should just have been added as an additional recursive case. Since this is done only once at query startup, worrying about hypothetical micro-performance issues seems rather misguided.
Habit mostly - why write code with potential performance problems when the alternative is just as easy to read?
I disagree with saying "it's just done at query startup so don't worry about it too much". Back in my days with DB2 we were working on the TPCC benchmark (when it was still relevant) and we found that the startup cost was a huge factor when doing rapid fire, cached, simple queries. In many cases the startup cost was >50% of the overall query execution time. Our testing here in Salesforce is showing a similar pattern in some of our workloads and PostgreSQL.
I'm not trying to argue that this particular issue of recurse/don't recurse is going to make or break anything. It's just where my head's at when I look at the code.