Vitsliputsli

существует ли какой-то инструмент который позволяет запускать SQL-запросы от аналитиков и чтобы это было прозрачно и с логами?
Рассматривали вариант репозиторий с CI/CD куда аналитик кладет свой SQL-запрос.

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

Кол-во параллельных операций в один момент времени зависит от кол-ва ядер процессора.
Только вот запрос к БД это не атомарная инструкция процессора, а значит СУБД может выполнять множество запросов, выставляя их на паузу в произвольном месте и переключаяясь на другие запросы. А как это будет, слишком завязано на сами запросы, что они делают, как блокируют друг друга, и от предпочтений СУБД.

Интерпретируемые языки исполняются построчно

Неа, интерпретируемые языки это те, которые исполняются не машиной, а программой-интерпретатором.
Работа php скрипта начинается с парсинга кода. Проводится лексический и грамматический анализ. Будет ли использоваться какой-либо промежуточный байткод здесь пока не важно.
В вашем примере, php парсер обнаружил неизвестную продукцию и сразу же кинул ошибку. Можно было, конечно, выполнить код до последней корректно определенной продукции, но зачем? Php старается уходить от устойчивости к стабильности, т.е. от "отработать хоть както" к "отработать обязательно корректно". "Хоть както" все равно можно, но это должен быть сознательный выбор.
И, хотя в php нет предварительной компиляции, тем не менее ошибки синтаксиса легко обнаруживаемы при запуске, поэтому логично о них сообщать сразу.
Что касается, зачем анализировать весь код, а не построчно, то это тупо быстрее даже без байткода, и дает преимущества по оптимизации. Например, если вы объявили переменную и присвоили ей значение, а дальше в коде нигде ее не меняли, то php сделает ее константой.

to_date(date_begin::text, 'DD.MM.YYYY'::text)

т.е. у нас есть поле date_begin в формате datetime, а мы его кастуем в текст. Затем из текста по какому-то непонятному формату получаем дату.

А все это работает скорее всего потому, что в php при подключении к БД используется формат даты 'DD.MM.YYYY', поэтому эта бредятина работает, а когда напрямую подключились к базе, там вероятно дефолтный 'YYYY-MM-DD' и получается чушь на выходе.

В общем удалите эту дикость и посмотрите как в PostgreSQL нормально получить date без промежуточного преобразования в строку.