Какой смысл в использовании шаблонизаторов?

Шаблонизатор шаблонизатору рознь. Но в целом следует выделить общие задачи. которые должны решать за вас шаблонизаторы. С blade не работал и не вижу смысла есть есть twig.

Безопасность. Это пожалуй можно поднять на верх. Типичная картина в шаблонах на php - <?= $someUserInput; ?>. Частенько это можно встретить в выводе инпутов, при формировании ошибок поиска (мол "по запросу $userInput ничего не найдено. То есть вставляем в инпут подключение наших js скриптиков, если это форма поиска - делимся с "другом" и забираем его сессию. Ну или еще какие забавные штуки можно делать. А ведь все очень просто решается. Ставим какую-то функцию, которая по умолчанию будет фильтровать XSS инъекции при выводе, и не будет этого делать только если мы попросим. Если писать просто на php - появляются отвратные функции, которые можно просто забыть вызвать. А с шаблонизаторами мы пишем красивые {{ someUserInput }} и можем спать спокойно.

Помогают соблюдать принцип DRY. Современные средства шаблонизации (twig например), предоставляют вам возможность разделять шаблоны на блоки, переиспользовать их несколько раз, выделять макросы, наследовать шаблоны... словом все что угодно. лишь бы вы могли реюзать куски html а не копипастить их.

Ограничивают полет фантазии разработчика. Далеко не новость что разработчики ленивые засранцы. Особенно молодые. Если им в шаблоне внезапно понадобились какие-то данные из БД, или данные связанные с запросом, большинство не будет париться и зафигачит нужный код прямо в темплейте. Так же некоторые грешат тем что часть бизнес логики размазывают по шаблонам. Так же встречал проекты отданные на суппорт, где чуваки в шаблонах разбирали через xpath ответы от сторонней апишки (которая использовалась вместо базы данных. То есть это дело было размазано по всему проекту). Рефакторинг в случае изменения апишки будет болью.

Хороший шаблонизатор должен настолько сильно усложинить вам процесс написания говнокода в шаблонах, что бы вы перехотели это делать и подумали как это можно сделать нормально. На выходе же мы имеем чистенькие шаблоны, которые ничего не знаю о бизнес логике приложения и знают только о логике отображения, чего мы и добиваемся вообще разделяя логику от представления. Это так же упрощает жить верстальщику (если он отдельно существует) или вам же в будущем при суппорте.

С другой стороны, тот же twig позволяет в рамках проекта расширять синтаксис шаблонизатора, писать экстеншены, словом делать очень много забавных и нужных вещей, позволяющих сократить время поддержки шаблонов в будущем.

Так как за все эти приятные вещи мы по сути ничего не платим (шаблонизатор должен компилировать все это в нативный php так что оверхэда просто не будет), почему бы не пользоваться?

Смотря о чем именно речь. Мешать верстку и логику - всё-таки плохо, и есть много на то причин.
С другой стороны всякие шаблонизаторы со специфичной разметкой на мой взгляд очень неудобны.
Сам пользуюсь вот таким методом:

function template() {
		if (!is_null($this->template) && is_file("template/{$this->template}.tpl.php")) {
			extract($this->data, EXTR_SKIP);
			ob_start();
			require "template/{$this->template}.tpl.php";
			$content = ob_get_clean();
			return $content;
		} else {
			throw new Exception('Не указан шаблон: '.$this->template);
		}
	}

По-моему, наиболее простой и удобный вариант.

Порядок использования конструкций шаблонизатора можно легко объяснить верстаку.
Что бы переводил свой PSD сразу в шаблон и оживлял его данными переданными из контроллера.

Можно конечно научить его работать и с PHP, но ненужная гибкость языка будет только осложнять понимание. Некоторые верстаки, воспринимают попытку подсадить их к PHP, как перекладывание части работы бэкэнд-разработчика на их плечи :)

кратко - шаблонизаторы поддерживают наследование шаблонов, не все верстальшики знают php, поэтому им проще разобраться с чистым html, по умолчанию включено преобразование html сущностей, что избавляет вас от xss injection.

Почитайте про возможности, например Twig. Мб проникнитесь. Интересная штука. Хотя при использовании Volt (читай Twig) есть много плюшек и синтаксического сахара, а также кучи дополнительных возможностей работы с шаблонами, но на мелких проектах их использование ставится под сомнение.
Многие путают понятие шаблонизаторов. Есть наподобие Twig и Smarty со своим синтаксисом, работой с layouts. А есть, обычные PHP-шные с short_tag'ами (@aspetek написал пример), где никакого своего "языка" нет, но также разделена логика.

Blade с натяжкой можно назвать шаблонизатором, он делает пару простых замен для более удобного синтаксиса, при этом в шаблоне вы можете открывать теш

Тут еще не упомянули про такой шаблонизатор как liquid. У него помимо эстетических функций есть очень важная фишка: он дает доступ к изменению вида (то есть того самого шаблона) и вы можете не опасаться при этом, что кто-то нехороший вставит в шаблон вредоносный код и взломает сервер.

Шаблонизаторы на мой взгляд абсолютно не нужная вещь, но при этом шаблоны (представление), разумеется нужны. Какие есть плюсы при использовании шаблонизаторов:
1. Более "красивый" и лаконичный код. Вместо <?= $var ?> мы пишем {{$var}}. Честно говоря не вижу тут особой разницы. Если нужен лаконичный код лучше применять как в Yii1/2 виджеты. Передал данные, сделал нужные настройки и у тебя готовая таблица с сортировкой и всеми делами, а не целое полотно кода.
2. Дисциплинирует разработчика и не даёт ему делать SQL запросы из шаблона. Очень сомнительный аргумент, если руки кривые всегда можно что-то сделать не так.
На этом плюсы и закончились переходим к минусам:
1. Тратиться много ресурсов. PHP нужно открыть, прочитать и проанализировать шаблон. С обычными шаблонами там несколько проще.
2. Чтобы не делать эту ресурсоемкую операцию каждый раз шаблонизатор кэширует результаты своей деятельности и тут получаем второй минус - приходится постоянно чистить кэш. При этом кэш не отменяет запросы в БД и остальные вычислительные процессы, которые совершаются в модели.
3. Надо учить дополнительный синтаксис.
4. Дополнительная сложность порождает дополнительные проблемы. Неоднократно встречал сайты, где иногда, данные не корректно скэшировались и сайт не работал.