safenoob

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

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

Действительно, это довольно удобно. Но в такой простоте есть риск выкатывания на production не протестированного должным образом кода. Использование системы continuous integration с настроенными автотестами дает некоторый уровень гарантии.

prodaction пишется как production

потому что в GIT не надо хранить настройки боевого сервера. В системе контроля хранят только исходники.
дальше их отправляют в CI (Непрерывная интеграция), которая в случае успешной сборки добавляет deploy скрипт под конкретный боевой production. И выкладывает на сервер, или выкладывает архив для ручного выкладывания.

ищем (наиболее) свободный сервер при заказе хостинга

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

Просто так это делать нет необходимости. Тем более в истории про "пару сайтов".
Этот процесс, в общем случае, вообще никак не влияет на безопасность.

Физическое отделение БД от приложения обычно нужно по каким-то конкретным функциональным причинам.

SELECT
id, title, cost, fr, btext, img, category FROM service WHERE category = 4 ORDER BY id