I personally believe that the main pragmatic issue, which lead to the development of more elaborate pure-templating languages such as TT, is that “the user interface is the one thing that is subject to the most Change For Change’s Own Sake.” Say, by the marketing department. The lead salesperson (who also happens to be the owner’s daughter ...) is worried about her commission, and she’s convinced that the reason why people aren’t buying is because the web-site doesn’t look like Competing_Site_X. So what this means is that the presentation-layer of the site is going to change ... a lot ... frequently ... and for what are basically non-technical reasons. And we all know what happens when the same code that does useful work keeps getting reworked ... code, like wrought iron, becomes more brittle the more you bend it.
TT compiles your template on-the-fly to Perl code and may cache that generated code on disk to avoid constant recompiling. It has become very elaborate because it is designed to be arm’s length from the non-presentation side.
These are issues that you, as the designer, are going to have to Meditate upon. There are many templating systems, and templating-system philosophies. All of them are in-service and working as designed. My preferences might be easy to guess from this, but I think that there is no bright-line rule.