Straight from the reference manual for Template Toolkit, we see the following example for the IF directive:

[% IF age < 10 %]
       Hello [% name %], does your mother know you're 
       using her AOL account?
[% ELSIF age < 18 %]
       Sorry, you're not old enough to enter 
       (and too dumb to lie about your age)
[% ELSE %]
       Welcome [% name %].
[% END %]
[download]

Here we see variable output based on age and we see the use of display logic to handle it. But, a different way to think about solving this problem is to have a controller dispatch to 3 separate sub-actions, one for each age bracket, each of which points to a different view. Why would one go to this trouble? Because it scales to possible model actions later: logging each visit based on age, for example.

In Catalyst code, using control logic to handle age:

package MyApp::C::Login;

sub login : Path('/login') {
  my ( $self, $c ) = @_;

  my $age = $c->req->params->{age} ;
  if ($age < 10) {
    $c->forward('under10');
  } elsif ($age < 18) {
    $c->forward('under18');
  } else {
    $c->forward('welcome');
  }

sub under10 : Private {
 my ( $self, $c ) = @_;

 $c->model('Login')->incr_under10;
 $c->stash->{template} = 'under10.tt';

}

# and so forth
[download]

Now this might seem like overkill, but consider this more extensive example of a server database for Catalyst whose view is implemented in tt. Instead of two views, one for user and one for admin, we have a number of IF and UNLESS checks for admin interspersed in the code.

So, to summarize.

1. moving "display logic" from templates to controllers can make HTML more readable. The extensive example above could be refactored into two pages, one for admin and one for users and therefore be more readable.
2. moving "display logic" from templates to controllers insures scalability should additional model actions need to occur atomically with certain view actions.