Vitsliputsli

Если подразумевается высокая нагрузка:
Т.к. параллелизм, то сервис лучше писать на Go, Python тут плохой вариант.
А вместо rest лучше grpc, если для модели нужно много данных.

Хочется вынести одно постоянно соединение api(или части запросов) на одно постоянное соединение. Остальной сайт и странички будут работать с множественными соединениями.

Выделите для api отдельный пул php-fpm воркеров из 1 штуки.

Если 204, то тело должно быть пустое, следовательно нужно будет дополнительно обрабатывать код 204. Либо не писать дополнительную обработку, и сделать как автор и предположил. По-моему, нет смысла в погоне заиспользовать как можно больше http-кодов, усложняя код, пусть и незначительно.
Касательно несуществующего ресурса, если он действительно несуществует как бизнесовая сущность, тогда 404. Если же мы просто не нашли подходящих строчек в базе, т.е. ресурс существует, но это пустой список, то удобнее ответить как и в предудущей ситуации.

От фреймворка требуется только читать данные из rest Elasticsearch, читать/писать в SQL через rest и рендерить страницы на стороне сервера ssr.

Вам не нужен фреймворк.

Фремворк поможет не быть зависимым от разработчика, сейчас эра фреймворков, и разработчики почти все фреймворк ориентированы (даже если он и не нужен)

Выбирать инструмент, потому что модно, не верный подход.
Зависимость от разработчика никуда не денется, фреймворк даёт только инструменты для структурирования, как ими распредиться зависит только от разработчика. Даже в MVC фреймворке нарушают MVC очень часто, а это просто схема разделения данных, со структурой все сложнее.
Фреймворк-ориентированный разработчик это чтото страшное, всякий, конечно, знает одни инструменты лучше других, но ориентированный это больше про того, кто освоил только молоток, и теперь для него все гвозди. Поэтому, если конструированием и архитектурой будет заниматься не специалист, а фреймворк, то вас ждёт много проблем в будущем, потому что инструмент в принципе не может этого сделать.