Generally, no. If you need to do output buffering, just use the output buffering API. Even if you need to retrieve your output to do post-processing on it, you can do that using ob_get_contents. It won't be a big deal on most pages, but on large pages or under heavy server load you should use the output buffering support because it's better optimized for what you're trying to accomplish.
Generally, when looking at a method such as what you're contemplating, ask yourself "what does this gain me?" Your example above is clearly trivial, but unless you're planning on post-processing your results, what does it gain you?
EDIT:
I've used both the PHP-in-XML and XML-in-PHP approaches in various projects. My experience is that on a project of any significant size the PHP-in-XML (or HTML, but I try to always generate XML or XHTML) eventually turns into nasty spaghetti code that becomes a pain to maintain, whereas the XML-in-PHP approach eventually balloons into a mess of string-manipulation code that you also don't want to maintain.
Generally, I'd recommend going with an MVC (MVVM, MVP, etc. - up to you) framework for every web app, regardless of language. If applied correctly, the additionally framework complexity is more than compensated by the modularity and ease of maintenance and extensibility that you gain. If you don't feel the need or desire to target a framework (though, again, I STRONGLY recommend it), I typically follow these rules:
- Whenever possible, limit PHP-in-XML to simple inclusion of values. E.g.,
<h1><?php echo $title; ?></h1> Try to avoid including logic in your spaghetti code (other than, perhaps, repetition, though I typically abstract that away, too).
- Whenever possible, create XML documents using the XML API's instead of writing raw values to the output. XML has the advantage of being easily transformable, which in my experience is well worth the extra initial investment, at least in production apps.
- Send the client an XML document representing your data with an
xml-stylesheet processing instruction indicating the location of a stylesheet to apply for rendering and let the client do its own rendering. Failing that, put your data-to-presentation transformation logic in a stylesheet (XSLT, not CSS) and do the transformation server-side. I really enjoy the separation between data and presentation it allows me.