Whereas I would chime in for Template::Toolkit, but the essential point is the same: you should, insofar as possible, clearly separate program logic from presentation.
If When the marketing department says to you, “that looks great, but can you just ... (insert complete page makeover here),” you should be able to do that just by changing a template. The program logic builds data structures (and provides functions), then the template iterates through them. “Separation of concerns.”
Templating systems have considerable power for just this reason. You can loop through data structures, make decisions, call Perl functions and so-on from within a template. (Usually, the templating system works by building and compiling a Perl subroutine on-the-fly.)
Postscript: This is one of the “lessons learned” of the PHP community ... and a hard lesson it was, because the intrinsic design of PHP
is originally was very-specifically to allow logic to be embedded into the HTML. Today, you won’t find any PHP pro doing that anymore (although plenty of legacy apps do and always will remain). They all use templates now, and objects, and the language and its user-contributed-source libraries have grown in these directions. While you may still find books that teach that approach, it is now widely recognized as a poor practice for the reasons aforesaid.