Oracle APEX штука конечно хорошая, все в одном. По форумам посмотришь, ну всем хороша: работает на уровне базы данных, RAD-средство, готовые формы и элементы есть. Народу нравится. Казалось бы, если инфраструктура конторы развернута на базе Оракла, чего бы не использовать? Народ что-то парится с JavaEE, с какими-то серверам приложений, мучается с ORM, с передачей сообщений между серверами, кластеризацией - вот же есть решение. А может быть людям просто жалко времени, потраченного на изучение всего этого, когда большой Оракл сделал такую прикольную штучку и все твои знания оказывается псу под хвост и достаточно знания только PLSQL? Долго искал возможности и недостатки Apex-а, ну вроде всем хорош, народ конечно приводит левые вопросы, можно ли сделать на нем Amazon.com, но это сами понимаете.
Жопой чую, ну не может такое решение быть панацеей от всех бед, практика да и может не зря же трехзвенку придумали, хотя на форумах Apex-а говорят, что она как бы нафиг не нужна.

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

Т.к. язык процедурный, то в нем нет таких вещей как паттерны проектирования, нет объектов тогда, когда они действительно нужны.

Все процедуры и функции работают либо с локальными переменными, либо с переменными пакетов, либо с данными, подгружаемыми из таблиц. Есть коллекции, но по функционалу они проигрывают Java Collections Framework. Для прохода по индексам коллекции тоже приходится писать неслабый код. Просто в таких языках как жава, в таких платформах можно иметь объекты уже просчитанные и загруженные в память, можно держать ссылку только на один объект и не париться. Дальше в оракле все выполняется последовательно, нету потоков, job конечно штука хорошая, но требует определенных телодвижений.

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

Сложности при интеграции с внешними системами, с их API.

Сложности в логгинге, программный код засоряется отладочными сообщениями, приходится либо самому писать систему логгинга, а не использовать общедоступную. Язык не лаконичный.

В отличие от java не обладает таким большим количеством вспомогательных библиотек. Приходится делать разные костыли, когда надо сынтегрировать с другими системами.

Сложности в тестировании бизнес-логики, отсутствие общепризнанных аналогов JUnit. Есть конечно варианты, но писать тесты на них тяжело. Аналогично тяжело задавать данные для тестирования.

Насчет кэширования ситуация неясна. Тысячи пользователей, каждый запускает некий сложный и тяжелый отчет, отчет ходит по базе, что-то такое вычисляет в job, т.к. ответ пользователю надо дать сразу, а отчет будет после refresh. Надо продумывать как это все будет работать одновременно, следить за очередностью, чтобы база на подвисла.

Как насчет использования apex в качестве складской системы или учетной? К примеру есть оборудование на складе и есть система, позволяющая делать заявки на склад, как она должна быть сделана, чтобы не было проблем? Ну там блокировки, конкуррентный доступ к одним и тем же данным. А когда товаров много? Опять писать костыли для решения этих проблем? Т.е. как Apex ведет себя в многопользовательской системе уровня предприятия, типа ERP или складской программы, в качестве системы которая используется одновременно и по-многу разными пользователями. Блог евангелистов Apex, металинк, AskTom (приложения на Apex) это все системы ориентированные на выдачу контента, это больше read, чем write системы. В этих системах как правило нет конкуррентного доступа к одному и тому же ресурсу.