Если вы пишете такие продукты, что уперлись в производительности в PHP - мое почтение. (хотя что-то мне не верится). Особенно с такими примерами кода.
Как правило логичным шагом при получении таких ограничений - переписывание узких мест на более производительных языках, как например поступают в Badoo. на C/go. А основная кодовая база ТАК выглядеть не должна ни при каких условиях.
Используется функциональный подход - так где функции высшего порядка? где отсутствие глобальных состояний? Ваш начальник не умеет ни функциональный подход готовить, ни объектно-ориентированный.
По факту - вашего начальника я бы не взял даже на должность джуниора - 15 лет писать вот такое, принципиально считать что твои велосипеды лучше всех сложившихся практик, и быть намертво уверенным в собственной правоте - это смерть для разработчика и для коллектива, в котором он работает, а если уж он еще и начальник в нем... Из-за таких как он и ходит в сообществе мнение о PHP как о плохом языке для обезьян.
Пока молодой и не научился такому же подходу - меняй работу, иначе потеряешь кучу времени и на этой работе, и на переучивание в дальнейшем.
Ну это как и у других - оффтоп с критикой твоего начальства.
Что касается именно кода - обрати внимание на PSR соглашения - по форматированию кода, именованию переменных, сделаешь код более читаемым (
www.php-fig.org/psr/) , это стандарт в индустрии и на скорость никак не повлияет, можешь даже начальнику показать.
Дальше познакомься с PDO и понятиям SQL инъекций. Код приведенный в вопросе абсолютно небезопасен, и то, что параметр $settings задается разработчиком - не аргумент. Новый джун может запросто туда отправить просто $_POST при сабмите формы - и вы никак от этого не защититесь. Код должен быть защищенным изначально, а не дырявым и "но вы эти дыры не используйте".
Листинги кода такой длины - нечитаемые, бейте на логические куски, книга Мартина Фаулера "Рефакторинг" в помощь, чтобы понять, как оптимально и правильно это сделать.