Звиняйте, но если вы не можете объяснить в чём лучшесть

ваших практик, то грош им цена. Мне начинает казаться что вы за них просто выдаёте ограничения инструмента.

Безотносительно ansible, зависимости - распространённая концепция, использующаяся много где, включая например разработку, управлении пакетами и разделяемыми библиотеками, и везде она работает замечательно и переносимо, и ни у кого не возникает мысли, например, в приложении на питоне указать в зависимостях все модули которые загружаются в процессе работы вместо только непосредственных зависимостей

Так вот не вижу чем использование зависимостей здесь будет отличаться. Собственно, расскажите как предполагается "правильно" действовать в ситуации описанного примера - есть "условный сайт" и есть "условный nginx" без которого он работать не может. Нужно поднять хост с этим сайтом.

Насколько я понял, предлагается "явно" прописать в playbook'е обе роли. Тогда:
- откуда вообще человек который пишет playbook узнает что сайту нужен nginx?
- что будет когда сайту перестанет быть нужен nginx, а понадобится апач?

Не извиняю, и вот почему. Я что-то объясняю только тем людям, которые готовы слушать и слышать. Таких, кстати, хватает на митапах, на работе, и даже недавно на конференции, не говоря уже про этот чат. А ты можешь делать так, как сочтёшь нужным. Дальнейшие набросы - прямой путь в R/O.

Улыбнулся на «зависимости в управлении пакетами работают замечательно»

Прописать роли явно в плейбуке - наглядно и читаемо Сносишь nginx, ставишь апач другой ролью, которую ставишь в плейбук вместо Nginx

стандартная практика в ролях просто указывать какие еще роли нужны. пример: https://github.com/geerlingguy/ansible-role-glusterfs#requirements