Saboteur

Надо тебе запустить три-четыре процесса (веб сервер, базу, какой-нить бот, какой-нить брокер и логер). Они могут требовать разные зависимости.

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

Ядро операционной системы умеет делать "контейнер", и процесс внутри этого контейнера думает что он в этой "операционке" единственный, сразу после ядра.
Ему подсовывается виртуальная файловая система, сетевые интерфейсы, дерево процессов коротенькое, он не видит ничего и думает что он запущен в отдельной виртуальной машине.

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

Приложение же состоит из одного файлика index.php и выводит текст "Hello World!".

php не умеет выводить текст в браузер. Это значит что в первом докерфайле уже устанавливается какой-то веб сервер, возможно httpd

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

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

вам не нужен cat и ненужный pipe - просто
grep -q "app start" /app/log

Но вы уверены, что это нормально - просматриивать целый лог файл каждую итерацию рединесс пробы?
Может быть все-таки лучше в программу добавить дополнительный ендпоинт и проверять ее через http пробу?

И второй попутный вопрос: правильно ли что dev и prod работают на одном и том же контейнере?

Вы имеете ввиду из того же докер образа? Так и надо делать. Чтобы тестировать и запускать в продакшене одно и тоже.
Енвайрнмент-зависимые вещи настраиваются извне и прокидываются (сертификаты, креденшелы для баз данных, и т.п.)

А так - если вас решение устраивает, если вам оно понятно и в случае чего вы его можете легко модифицировать как вам нужно - да, вполне нормально.

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

Монорепа/мультирепа

Это вопрос для девелоперов, как вам удобнее. Монорепа используется обычно тогда, когда у ваших сервисов реально есть общий код. Если же нет, то проще в отдельных репозиториях.
Многие CI/CD можно настроить на пуш в определенные подкаталоги, и тогда разные сервисы в монорепе будут триггерить свои собственные джобы (teamcity например)

Версионирование

На усмотрение разработчиков. В мейвене есть плагины для автоматического semantic версионирования. Или можно руками. Самое простое - это мажорную версию проставляешь руками, а ci просто номер билда дописывает и/или хеш коммита в версию.

Откат

В случае с кубером/опенщифтом для этой задачи существуют healthcheck пробы, которые настраиваешь и все. Если приложение не прошло хелсчек при поднятии, то деполй фейлится и все - предыдущая версия автоматом будет продолжать работать. В случае баз данных и других вещей - разработчики должны писать скрипты для наката/отката, или если база маленькая можно делать бэкапы или снепшоты. Тут зависит от архитектуры

Как обновить 2+ сервиса одновременно.

Все верно. Либо у вас порядок деплоя сервисов предуказан в процессах, либо наполовину руками выводить. Но по хорошему такие несовместимости не должны приводить к крешу сервиса. Ну не будет временно работать фича Б в сервисе, потому что недоступен другой, и все. Поднимется этот другой сервис и все заработает. Это правильный и идеальный вариант, не мешающий деплойменту. Деплоймент проводится в небизнес время и никого не аффектит. Как минимум, подобные ситуации должны встречаться не так часто, поэтому вполне можно найти промежуток времени для таких нестандартных деплоев.

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

И конфиги и секреты можно маунтить и как файлы и как переменные окружения. Дочитайте документацию.