Additionally, a good template language does not require knowledge of coding. I've had considerable success with providing front-end HTML writers with templates based on purely declarative custom HTML/XML tags.
Programmers write and document the tag libraries, HTML developers use them, and the HTML templates themselves are simple, easy to read, and generally declarative.
I don't think I ever saw an effective template language that doesn't require programming knowledge. The only exception is when you move all logic in tags, but even then logic gets mixed with presentation (just not in the main template), and the downside is that a tag is like a black-box ... if the scope is not clear, you have no way of knowing what it produces by not looking over its code (CSS files in ASP.NET end up containing general classes in most cases because of that).
That's because the presentation layer requires logic, for example ... if this happens, then show this, else show that. Or to show the breadcrumb, iterate through this list. Or is this DateTime value in UTC? Then show it in the user's locale. That's logic and it's a lot more then a template with holes in it to fill.
And where is this logic supposed to go if not in the presentation layer?
There is power in a template paradigm. Much like MVC is for people who "can't handle" hacking their entire program into a single executable, convention (guided suggestions or limitations) can do a lot for a group of developers even if they aren't collaborating with designers. If they don't recognize that, so be it (they will) but calling convention a softball for the less manly application developer is a crudely un-meditated suggestion.