Сам по себе ORM, именно как maaping, в крупных проектах нужен как раз очень сильно. Опишу здесь свой опыт. Если понравится кому, может и статью потом.

Итак.
Представьте себе — у меня есть очень крупная система, и есть в ней таблица orders, в ней скажем, 50 колонок (на самом деле у нас 150, ну да ладно. Нормализаторы, молчать! Про нормальные формы я тоже знаю). И вот надо значит вам выбрать один ордер и показать его на экране. Допустим, вы пишете селект, неважно. Дальше что делать, в промежуточном слое? Вы не же вызываете хранимую процедуру (запрос) напрямую с, скажем, JSP страницы (я надеюсь), вам все равно надо получить данные и передать их как-то.
Так что, передавать их в виде массива, ArrayList-a, ассоциативного массива имя колонки/значения? Ну так дико громоздно, неудобно, и очень легко ошибиться. А если вам надо несколько ордеров, тогда что, создавать вложенные коллекции для конвертации результатов? Неудобно же.

Потому, очевидно, нам нужен объект Order, имеющий все нужные property, и нужен код, который умеет конвертировать результаты скл запрос в эти объекты (или коллекцию этих объектов).

Далее, очевидно, что писать руками _все_ запросы трудно и нудно, легко ошибиться, т.к. в Java они будут представляться в коде в виде строк (а значит, никакой статической типизации и compile-time проверок и прочее и прочее), и их надо держать либо в Java коде (если они мелкие), либо, если побольше, выносить в отдельные XML файлы.

В общем, ORM в больших проектах нужен для упрощения рутинной части. Без него — никуда :)

Безусловно, обойтись ТОЛЬКО ORM не получится. Есть у нас масса мест, где сложная логика написана в хранимых процедурах в 500-1000 строк на PL/SQL, написанная через ORM /Java она бы занимала в 10 раз больше и работала в 2 раза медленнее (при этом, она была бы еще и менее понятная, т.к. есть такая логика, которые в терминах реляционной алгебры описывается куда проще, чем в терминах ООП :), следовательно ложится на ORM со скрипом). Сколько нибудь сложные запросы с подзапросами, юнионами, хитрыми джойнами тоже писать через чистый ORM громоздко. Оптимизировать запросы, работающими в таблицах где, хотя бы, несколько сотен миллионов записей, без доступа к планам SQL оптимизатора и статистики/средствам мониторинга уровня СУБД тоже крайне сложно. Так что без SQL тоже — никуда :)

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

Упрощенно говоря говоря, в функциональном анализе, а не в чистом вариационном исчислении, функционал это просто частный случай оператора, отображающие множество (линийное пространство) в (действительное) число. Точное определелие можно найти в учебнике Смирнова, но имхо, определение которое вам дали под номером 1 — неграмотное.

Мне не режет слух употребление слова функционал в нематематическом смысле.

И никто не спросил — а ЗАЧЕМ это нужно? sys-id на то и auto-increment, что выдается sequence-генератором раз и навсегда. Зачем вы хотите это сделать?

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

Без этого трудно писать не-быдлокод.

У меня есть в черновиках несколько статей по Java и JVM тематике, но все никак руки не дойдут их допилить и выложить, извините :(

Был бы признателен если кто прокомментирует — чего бы больше хотелось почитать. Тогда я как то приоретизирую и постараюсь найти время в ближайшее время.

1) Java — Atomitcs и неблокирующие алгоритмы в Java, concurrency.
2) Java — как работает внутри Reflection.
3) Groovy — как работают внутри замыкания, мемоизация замыканий, рекурсивные замыкания и лямбды.
4) Метапрограммирование в Groovy — AST-трансформации и Meta-Object Protocol.