One argument that is used to sell templating is that it would separate the code from the design. The same effect can be achieved with PHP, without the actual templating engines. If the templating engine is sophisticated /flexible enough, it does separate the PHP code from the HTML, but includes "the template code" into the HTML, thus recreating the problem it set out to solve.
Another argument is that templating would allow non-programmers to design a site. I don't buy this at all. (Note that I'm not implying that Martin thinks this is so, he just said it is one of the ideas behind the templating.) No visual editors that I know of support templating to a degree that this would be true. Even if the editors would be smart enough, this would drive towards very basic user interfaces: no things like "enable these boxes if that box is selected", "display these in two columns if there are ten items or more, otherwise in one column"... Designers should always understand enough of the nature of web pages and web applications, otherwise you'll end up with beautiful layouts that are very hard or impossible to implement. With the templating code still there, the designers would have to know "too much" about the internals of the application anyway to be independant of the coders.
And what designer would really do all those 100+ templates for Moodle for example?
Some say that with templates it would be easy to change the whole layout of the application without touching the code. This is much more easily done with CSS, as there is less CSS code that there would be templates and template code.
One advantage that some templating engines have is a natural way to run functions "out of order". Usually with PHP they have to be ran from top to bottom, screenwise. I find output buffering catching and string replacements a bit kludgy/hackish, though that is an efficient way to put things "up there".