Почему были исходные авторы Django против, включают теги?

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

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

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

В качестве тривиального примера я хотел показать список аватаров пользователей. Используя include, это выглядит так:

{% for user in users %}
    {% with user.gravatar_url as avatar_url %}
        {% include "foo/bar/avatar.html" %}
    {% endwith %}
{% endfor %}

С пользовательским тегом:

{% for user in users %}
    {% gravatar user.email %}
{% endfor %}

Использование пользовательского тега включения означает, что логика хэширования Gravatar больше не должна быть заботой модели User или функции представления.

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

Например, я написал приложение для блога (а кто не писал?), которое имело два типа архивного представления: базовое последовательное, с X постами на страницу, и ежемесячное архивное представление. Оба шаблона, очевидно, имели список постов в своем контексте, оба использовали один и тот же фрагмент шаблона summary, чтобы показать заголовок и отрывок из каждого поста, но каждый шаблон представлял их в немного разном контексте. Поэтому я использовал:

{# in archive_index.html #}
{% extends "base.html" %}

{# some stuff specific to sequential archives here #}

{% for post in posts %}
    {% include "post_summary.html" %}
{% endfor %}

{# probably more stuff specific to sequential archives #}

И...

{# in archive_monthly.html #}
{% extends "base.html" %}

{# some stuff specific to monthly archives here #}

{% for post in posts %}
    {% include "post_summary.html" %}
{% endfor %}

{# probably more stuff specific to monthly archives #}

Кажется, что в данном случае композиция имеет больше смысла, чем наследование. На самом деле, сначала было трудно представить, как здесь вообще может работать наследование. Ну, это все еще возможно:

{# in base_archive.html #}
{% extends "base.html" %}

{% block archive_header %}{% endblock %}

{% for post in posts %}
    {% include "post_summary.html" %}
{% endfor %}

{% block archive_pagination %}{% endblock %}

Теперь два разных архива расширяют это и просто вводят свои уникальные материалы в блоки:

{# in archive_monthly.html #}
{% extends "base_archive.html" %}

{% block archive_header %}
    <h1>Archive for {{ month }}</h1>
{% endblock %}

{% block archive_pagination %}
    {# previous/next month links here #}
{% endblock %}

Я оставлю представление о том, как выглядит archive_index.html в качестве упражнения для (несомненно, скучающего) читателя.

Фух! Чувствуешь себя умным, что придумал способ делать одно и то же, используя и композицию, и наследование, но не является ли последнее просто изгибом назад, чтобы соответствовать догме, которую упомянул Джейкоб Каплан-Мосс?

Только что посмотрев видео (да, все 1 час 5 минут, только чтобы я мог закончить отвечать на этот вопрос), я не думаю, что Джейкоб был бы сильно обеспокоен. Это прозвучало как замечание не по делу, возможно, ссылка на то, какую технику вы должны рассмотреть в первую очередь.