The reason why it makes sense to use an entirely different language for the templates is quite simply to avoid using Perl. You may be very proficient in writing Perl code, but quite often the people who deal with the templates (and in general the 'View' part of the equation) are web designers. Those people are more likely to be better at HTML and CSS, and it therefore makes more sense to teach them how to use a simple template syntax (% s.name %) instead of teaching Perl (print $s{name}).

Even if all your web designers are Perl hackers, I think it still makes sense to learn a different templating language just for the sake of code clarity. I find it much easier to do all the hard work in my Perl in my Controller class, shove those variables in the stash (I use Catalyst), and then simply print and loop through the variables with the Template Toolkit.

All in all, TT is a very powerful system, and a language of its own. I once designed an entire web page that didn't need any "real" dynamic content, so I didn't have to write one line of Perl code: the whole thing was developed using Template toolkit and the ttree helper application.

The reason why it makes sense to use an entirely different language for the templates is quite simply to avoid using Perl
If I may add to this... In one of my past projects, we used templates "of our own" to present data in tables and graphs. Because of short deadlines and heavy workload, we eventually had to fix some bugs here or there and because of the same-language commodity (as well as a few other reasons), we started mixing together the template code and the logics... ...which naturally impacted the development of future modules forcing me to save HTML tags with the data inside the database (yeah I know! that's a horrible thing that still gives me nightmares but I'll get over it eventually).

So I think it's really worth separating data and logic. And language isolation is also a good thing since it protects you from yourself.