That seems to be unrelated to the concern here (as belied by the grandparent citing magic_quotes). XHP (like plain PHP, for that matter) can be used in a way that, for all intents and purposes, separates the concerns of presentation and logic. It's more a matter of convention than constraint.
The purpose of a "layer" is not determined by the language it's implemented in, but by what the code actually does. Code that handles nothing but presentation is by definition separate from the business logic, even if the presentation code and business logic are implemented in the same language. It is trivial to implement this architecture with PHP and even easier with XHP.
Lazy/bad developers will always find ways to put business logic and presentation in places they don't belong. I like systems that -- rather than enforcing arbitrary and inevitably leaky constraints -- aim for maximum productivity and power in the hands of capable developers.
Let's take a real case: Smarty. To my eye, XHP is going to take a huge slice of the PHP template system market away from Smarty. The reason is that XHP gives you the native constructs of PHP (sans mind-bending hacks -- try referencing a class constant in Smarty) while staying at the right level of abstraction for fast development: chunks of valid XHTML.
Anyone who's spent the 1990s coding Perl CGI will tell you just how big of a step backward this is.