Разверните стенд, попробуйте. Пока не пощупаете руками - не поймете.

Нет такого, что рекомендуют или не рекомендуют. Все зависит от вашего проекта. Те доводы, которые здесь перечислены насчет CI итд - правильные. Дополнительным аргументом в пользу deploy-скриптов может быть, например, необходимость изменения схемы БД на проде с очередным апдейтом, чего git не сделает сам по себе. Плюс, обновление через git - не очень рабочий вариант в случае компилируемого кода. Конечно, можно навернуть поверх гита каких-нибудь билдеров, но этому уже точно на проде не место.

Но если, например, проект простой, компилируемого кода нет, и в команде есть договоренность о том, что в master попадает только протестированный код, то никакого криминала в том, чтобы сделать git pull, нет.

Ответственность контроллера в MVC:
1. Получение параметров из представления (GET/POST итд) и передача их в модель
2. Возврат представления с параметрами, полученными из модели
3. Валидация и фильтрация параметров в обе стороны
4. Контроль доступа на основании правил, заложенных в модели

То есть контроллер - это посредник между представлением и моделью. Контроллер по возможности не должен содержать бизнес-логику. Представление по возможности не должно вызывать методы модели напрямую, модель gо возможности не должна содержать примеси представления (HTML) и возвращать представление. "По возможности" - так как не всегда это возможно/оправдано с точки зрения трудозатрат разработки.

Общее правило: тонкий контроллер и толстая модель.

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

Специфика веб-приложений в том, что на каждый запрос клиента создается новый экземпляр приложения, так как HTTP(S) - протокол без сохранения состояния (stateless).
Для всех клиентов существует один общий класс контроллера (class myController), но на каждый запрос каждый клиент получает собственный экземпляр контроллера (new myController)

если один пользователь запросит экшен1, а второй пользователь после этого запросит экшен2 - не может ли он получить значение "9"?

нет, второй пользователь получит 5, так как взаимодействует с собственным экземпляром контроллера.

Не нужно распыляться на полутора человек пользователей с дисковыми телефонами или текстовыми браузерами. В одной крупной интернет-компании действует общее правило, что браузеры с < 1% суточной аудитории не поддерживаются. В абсолютных числах это тысячи посетителей в сутки - от них сознательно отказываются чтобы сфокусироваться на массовой аудитории. ID сессий в коде или урле это очень-очень плохо, так как кроме явно костыльного решения, это чревато попаданием сессий например в поисковый индекс со всеми вытекающими

Оба подхода не очень хорошие, так как смешивают логику аутентификации пользователя с логикой протоколирования событий. Условно у вас есть 3 модели: User, Session и UserLog.
Связь UserLog и Session опосредованная через User. Такой подход позволит вам а) организовать хранение сессий в виде "1 пользователь - 1 кука", б) даже если у пользователя умерла кука и ему выдалась новая, вы сохраняете историю пользователя, тк UserLog привязана к User через внешний ключ.