Apart from the performance/capacity “edge cases” that I openly acknowledge BrowserUK (in particular) deals with every day, my bright-line rule always tilts in favor of: clarity, and maintainability. In the world that I live in every day, it is “six o’one, half a dozen of the other” in terms of performance ... because raw speed in my world is rarely actually the issue. (And to the extent that it may be, I look for a deeper algorithm change.)
Certainly, to me, the first example is clear, and the second example would instantly fail my code-review: in the second case, the code does not plainly say that parse_node() will be called once vs. twice. I emphatically do not want to have to “understand Perl” in order to understand what a line of source-code says. I want it to very plainly and unambiguously say precisely what it means. (And if the compiler’s optimizer can improve upon it, goody for the optimizer and thank you for the freebie.)
Spoken from the point-of-view of a businessman who did lose $10,000.00(USD) in actual cash, that he most-emphatically could not afford to lose but also could not rightfully keep, due to code written by someone else that was not clear. The cause of project-death was “cleverness.” I could not find the bug because I could not identify it. I had to borrow money fast.