> то есть вообще не спец

Раз уж вы спросили. Я двадцать лет (точнее, уже чуть больше) с Ораклом работаю. Я и есть тот самый DBA (сертифицированный, если что), о котором вы тут разглагольствуете. По совместительству - программист. Работаю с клиентами по всему миру.

На всякий случай, потому что вы явно не в теме, но зачем-то пытаетесь выглядеть экспертом. У Оракла, если денег не жалко, есть специальные инструментальные средства, которые вполне сносно (хотя и не во всех возможных случаях) справляются с оптимизацией сложных запросов. 19-я версия даже индексы может за вас построить. А простые запросы щёлкаются оптимизатором как два пальца об асфальт. Главное - свежую статистику вовремя собирать.

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

> Настолько удобный что у 100% изучающих SQL возникает диссонанс в голове

Вот зачем вы свой не особо успешный опыт проецируете на всех? Убедительности вашим словам это не добавляет. Просто признайте, что у вас нет таланта к этому занятию (программированию) в целом, и языку в частности. Не ваше это призвание. Это нормально, и ничего обидного здесь нет.

> люди изобретают PLSQL

PL/SQL изобретён для лучшей модульности, контроля типов и облегчения взаимодействия с внешним миром. SQL - непроцедурный язык. PL/SQL - процедурный. Оба инструмента хорошо дополняют друг друга.

> и непереносимые расширения

Непереносимые решения создают, потому что вендор хочет привязать вас к своему продукту. Но ведь на современном этапе это обходится. Всякие ORB и тому подобные технологии изобрели как раз для этих целей. Поэтому если изначально подходить грамотно к архитектуре приложения, никаких нерешаемых принципиально проблем с переносом на другую более-менее развитую СУБД не будет. Вы там про Питон упоминаете ниже. Неуж-то не слышали об SQL Alchemy? Вот это одно из таких решений.

> Когда начинаются 3-4 вложенности с джойнами даже с комментариями лично мне тяжело сразу понять что творится

Если это комментарии в стиле "а вот тут колбаску заворачиваем", то и неудивительно.

Уверен, у вас были бы ещё бОльшие проблемы, займись вы разбором какой-нибудь объектно-ориентированной библиотеки классов с тремя-четырьмя уровнями иерархии и множественным наследованием. SQL в этом плане намного проще и прозрачнее.

Для того, чтобы с SQL дружить, надо хоть немного алгебру реляционных отношений знать. Также необходимо понимать, что такое множества, какие операции с ними возможны. Ещё важно знать структуру данных, с которыми вы работаете: какие функциональные зависимости между таблицами, как они нормализованы, какая кардинальность у полей.
Это то же самое, что для обычного программиста знать алгоритмы и структуры данных. Базовые знания, то есть, для работы с реляционными СУБД.

> лично мне проще написать скрипт на питоне который получит простыми запросами данные из таблицы, обработать как нужно и сформировать итоговый запрос

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

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