usr58

1. Единственное отличие в том, что Subscriber определяет сразу несколько слушателей.
2. С помощью Subscriber'а удобно подписываться сразу на несколько событий одного класса. Например, Doctrine - можно сразу подписаться на postPersist и postUpdate и зарегистрировать один Subscriber. Если это же делать через Listener, то придется для каждого события создавать свой Listener и отдельно регистрировать его.
3. Если вы зарегистрировали Listener/Subscriber через Service Container, то вызывать EventDispatcher вам не нужно. Если же вы хотите подписываться на события в runtime, то тогда да, вам придется вызывать EventDispatcher.

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

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

UPD подведу итог, я бы рекомендовал
1) использовать кастомные твиг функции, когда требуется какая то сложная логика или запрос данных из системы, но не рекомендовал бы ее для генерации html, просто потому что html в пхп не гуд. но в кастомной функции вы можете вызвать render другого шаблона, это норм, просто может ухудшить поиск верстки для фронтендеров (в случае инклюда для них все очевидно).
2) макросы - для кучки небольших вещей которые используются часто и повсеместно (инпуты)
3) инклюды для остальных кейсов, то есть когда данные уже есть и нужно их оформить в html

Бандлы - самодостаточные модули инкапсулирующие какие-то сервисы и прочую штуку. По сути это расширения для DependencyInjection, если очень грубо.

Модели - это те самые Entity грубо-говоря. Вообще есть такое понятие как Доменная-модель. Это просто структура данных, сущности которыми оперирует бизнес логика. Последняя должна быть инкапсулирована в сервисы (всякие UserManager, PostManager и т.д.). В Yii модели смешаны с сервисным слоем и по этому у вас получается путаница.

Что до кода... есть распространенный подход иметь свой AppBundle и фигачить все в нем. Есть так же рекомендуемый подход - не использовать бандлы вообще. То есть.... бандлы должны быть самодостаточны и их основное предназначение - реюз логики между проектами. Бизнес-логику приложения реюзать у вас не выйдет, поэтому рекомендуется просто писать код и регистрировать его в app/Resources/config/services.yml или что-то в этом духе, как именно решать вам. Профит в том что вы на замарачиваетесь всей этой фигней с бандлами и у вас возникает меньше вопросов по структуре. А если же вы захотели что-то вынести в бандл - например сервисы для авторизации которые реально можно реюзать, то вам никто не помешает это сделать. В итоге у вас будет структура проекта приблизительно такая:

| - app
| - var
| - src
  | - Controller
  | - Entity
  | - Bundle/
    | - MyAuthBundle/
| - web

ну как-то так. Как не странно такой подход не сильно распространен в Symfony-сообществе хотя его рекомендуют в недавно вышедшем бест практис буке и в принципе эта струтктура более чем логична.

Что до виджетов, в Symfony2 есть HMVC. То есть вы можете сделать эдакие под-запросы на другие контроллеры внутри вьюшек. Можно скажем все "виджеты" инкапсулировать как отдельный контроллер с методами и дергать их из вьюшек.

<div id="sidebar">
    {{ render(controller('AcmeArticleBundle:Article:recentArticles', {
        'max': 3
    })) }}
</div>

Это дает больше гибкости, внутри каждого контроллера можно дергать другие контроллеры. Можно прикрутить кеширование на уровне обработки запросов (кешировать скажем все подзапросы по каким-то критериям) и т.д.