Тут коллега высказал интересный тезис: программисту нет нужды знакомиться с нюансами реализации той или иной СУБД, будь то MSSQL, Oracle. Это, дескать, задача администратора – подкручивать всё для оптимизации производительности.

Тезис ложный. Администратор не имеет право менять код запросов. Многие сложные запросы без изменения кода запроса оптимизировать невозможно.
Человек, который так говорит - последний ламер в СУБД.

А разработчику достаточно знать стандарт SQL92 и вперёд.

Стандарт большинством поддерживается только на entry level. На нем много
не напишешь.

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

Либо этот код никогда реально не работал, либо это тривиальнейшие запросы типа INSERT/UPDATE/DELETE/SELECT одной записи. Либо он просто врет или выдает желаемое за действительное.

P.S. Коллега – java developer и, судя по его словам, уже 10 лет придерживается такого подхода.

Странно, как он с таким подходом продержался так долго.

Не, ну нам тоже товарисчи с такими подходами писали складскую систему (On-line отслеживание размещения , оптимизация перемещений). Да, они действительно могут свою базу в любую СУБД записать. Но в итоге из-за полного их ламерства именно в вопросах СУБД (в остальном к счастью не все так печально) у нас были достаточно серьезные проблемы, и решать их приходилось уже нам. Причем ошибки были действительно ламерские - начиная от неправильных индексов и кончая разными типами данных в полях PK и FK, который на него ссылается (при этом сами FK у них естественно как класс отсутствовали).

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

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

Интересно, откуда берется такой максимализм в высказываниях.

Из опыта.

задержка в 1-2 микросекунды просто страшно подумать к чему приведет

Если речь идет о СУБД, там время выполнения запроса начинается от
милисекунд. Микросекунды - это очень мало.

Есть смутное подозрение что для большинства баз (я не утверждаю что для всех :) ), абсолютно все равно полезут к ним через специализированный язык сервера

А что, еще как-то к серверу можно "лезть" ? Вроде бы нет.

или через какой-либо промежуточный объектный уровень вроде EJB, Hibernate, JDO

Ну и ? Последный все равно на SQL будет к серверу обращаться.

Тред чем-то напоминает аналогичные годов 80-90 ASM ws С/C++ - приходили к нормальному здравому решению - критические участки писались на asm, основная масса на C. С БД тоже, кстати, видел подобные решения (по правилу 80/20 :) ) и все это без проблем работает.

Вот именно, SQL - это как ASM , он непереносим на другую платформу.

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