the case of phpBB templates
The first template engine I worked with was the phplib engine used in phpBB templates. At first, like many, I thought it was amazing. I could edit these template pages and voila, the result would show up on my forums and I never had to mess with the php code.
Now that I have "matured" a bit in my understanding of templates (thanks mostly to Vincent) I realized a very, very critical point. Templating is NOT an engine, it is an idea. Pulling the presentation layer away from the code so that you don't have to modify the source code to get a different look can be done using PHP+CSS because it is not an engine, but simply a way of dividing up the tasks.
This actually became apparent to me earlier while making a "MOD" on my board. I realized that if you want to change the presentation of the forum, it is actually necessary to modify both the code and the templates. It is the case that the templates can actually get "outdated" as the code refactors. To me, this is not right.
The templates should be "logic-free" widgets. You should probably have one main template that does the primary painting on the page (header, footer and sidebars) and then for each widget you add, it should populate and insert the contents of its result. For instance, if my application had a list page, where I showed a paginated list of items, the "list" template should be used. That way, if I later added a new "box" on one of my pages that showed a list, I would not have to change the widget template (unless of course the template was bad to begin with). Look at this forum and try to put your finger on the different widgets it uses, and make a template for each of them. Many of these templates will be very small, and you simply include them when the data is ready and buffer the result to be used in the main template.
This follows what Vincent pounds in our heads of code reuse. If you think about it, phpBB templates repeat html code all over the place. They have a template for posting, template for viewing forum list, template for viewing message list, template for searching, template for search result list. That is TONS of repeated presentation layer code. If they had narrowed it down to widget templates (whether the tempates are PHP or some language it doesn't really make a difference) they could have reduced the amount of work the template artist had to do.
So whether you choose to use PHP (like me) or you choose to use "insert favorite template engine of choice," you should think of your templates as widgets instead of as page-specific templates, with one or two "main" templates that wrap the entire page in a basic layout. And the nice thing about this method is that you will see your widget "refactor" themselves as new situations present themselves, but never will you have to modify 20+ templates to make a new style. Try to consider "merging" similar widgets together that only differ by class definitions and come up with standard class names just like Qt or GTK. For instance, if you use a sideblock, but some are red and some need to be green, instead of making several templates for almost the same code, try to make the classname dynamic on the block or something like that.
By the way, if you are interested in a template engine that is just php with alternative wrapper tags, check out HTML_Template_Xipe in PEAR. All it does is let you change the tags used for php, eliminates the need for brackets by using indentation and does courtesy "echo" statements when a simple variable is enclosed in the tags. It is simply a layer between the designer and the cached version which allows you to type less and get a php result page. In the end I will just type the php thanks and skip the processing, but since they can be cached outside of the program being run, you can just create the template when the designer hands it to you and drop it in place (maybe use a commandline script).