Зачем работать с базой ORACLE только через процедуры?

Нормальный подход. 20 лет назад он был фактически стандартом.
Разработчик баз данных обычно стоит дороже PHP разработчика.
Сейчас, обычно, такой подход используют в корпоративных разработках, где могут позволить держать таких специалистов.
А в mysql еще совсем недавно не было никаких хранимых процедур. С тех пор так и пошла мода всю логику запихивать в сервер-приложений.
Это ни плохо и не хорошо, нужно идти от задачи и знать сильные и слабые стороны размещения бизнес-логики в сервер-приложений или в сервер базы данных.
https://habrahabr.ru/post/219445/

Простейшая ситуация: update нескольких таблиц по результатам отбор из других .
Отдельные запросы "извне" рискуют не выполнится (например обрыв связи). Инициации транзакций в такой схеме - чревата при том же обрыве связи их незавершением.

А процедура - можно считать ее неотъемлемой частью БД - гораздо меньше подвержена всему этому. Ну и как бы "атомарна" в рамках реализации бизнес-логики.

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

У меня был опыт участия в написании системы OLTP, в которой был достаточно высокий темп апдейтов, причем часто апдейтились одни и те же записи (из разных транзакций). Для того, чтобы избежать задержек, нужно было обеспечить быстрое завершение транзакций (явный commit или rollback). Если клиент обращается к БД не через хранимые процедуры, то управление транзакциями выполняется на стороне клиента, а значит, если клиент поведет себя некорректно (не станет быстро завершать транзакцию), или возникнут проблемы со связью в середине транзакции, то записи, которые апдейтят многие транзакции, окажутся заблокированы этой подвисшей транзакцией. Если же клиент взаимодействует через хранимые процедуры, то управление транзакциями осуществляется из таких процедур (явно начинается и явно завершается в одной и той же процедуре). Это минимизирует время транзакции. Для нас это было одной из основных причин применения хранимых процедур. Хотя, конечно, существенно было и то, что минимизировался трафик между клиентом и БД. На мой взгляд, эти две причины имеют достаточно большое значение именно для OLTP.
В другом проекте (на MS SQL) были огромные объемы исходных данных. Для сокращения размера БД было разработано очень специфическое представление данных в таблицах, так что эффективно можно было выполнять только некоторые предопределенные запросы с обязательными параметрами. Если в этих запросах не задать обязательные параметры и/или добавить дополнительные условия, то оптимизатор мог запросто выбрать план выполнения, при котором сервер "уходил в себя" (результата дождаться было просто невозможно). Однако заказчик требовал обеспечить ему доступ к этим данным (например предоставить некие views) из его приложений. Если бы мы предоставили ему views, то при использовании их он мог бы не задать обязательные параметры, задать дополнительные условия, перевязать эти view с какими-то другими таблицами/views/подзапросами. При выполнении таких запросов запросто возникли бы проблемы с производительностью (причем, всего сервера БД). Мы передали заказчику набор хранимых процедур с обязательными параметрами (не задать их он уже не смог бы), возвращающие резалтсеты, которые он может вычитывать точно так же, как при выполнении обычного запроса.

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

основная причина - пхп это не типизированный язык, тяжелую бизнес логику на таком писать моветон. оракловый pl/sql типизированный язык, глубоко интегрирован с данными. в пхп ты обновил код и только можешь помолиться, что код пхп ожидает те самые данные, что в базе. если кто-то удалил таблицу, пхп код об этом ничего не знает. процедуры в оракле знают к каким таблицам обращаются, знают какие типы колонок. т.е. если ты накатил на базу кривой патч, сразу это видно, затронутые процедуры станут инвалидными и оракл не позволит целиком запустить кривую процедуру. пхп код же пока не наткнется на косяк, не будет подозревать о засаде.
плюс тяжелую бизнес логику на pl/sql проще писать, т.к. можно привязаться к типу таблицы объявляя table1.name%type, table1%rowtype. плюс можно писать гораздо более эффективный код, оперируя данными конструкциями типа bulk collect, bulk insert.

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