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

PHP, а особенно 5 версия языка, является языком, поддерживающим как объектно-ориентированную, так и структурную парадигмы программирования. Сегодня все больше PHP-программистов использует объектно-ориентированный подход при разработке своих проектов. Дело не только в том, что люди вот так сразу поняли удобство этого подхода, в растущей мощности серверов (объектный код больше грузит сервер), появлении "чистых" объектно-ориентированных библиотек (работа с XML, библиотека mysqli), более важно удобство работы команды и дальнейшее сопровождение кода.
Но не все, что начинается с <?php class MyClass{...} ?> можно назвать объектно-ориентированным подходом. Я знаю достаточно "программистов", которые считают, что класс - это просто набор функций, объединенных каким-либо общим понятием, и никогда не слышавших трех слов, которые и кроют в себе парадигму ООП: инкапсуляция, наследование и полиморфизм. Рассмотрим эти три понятия по отдельности, а заодно подумаем зачем это все нужно.

Инкапсуляция - это сокрытие данных от пользователя внутри объекта класса, то есть, написав класс, Вы должны предоставить конечному пользователю только интерфейс класса, но не его реализацию. Почему? Давайте разбираться. Когда вы заводите двигатель машины, причем практически любой машины, вы просто включаете зажигание, может выжимаете сцепление, поворачиваете ключ в замке дальше, чтобы задействовать стартер и все... двигатель работает. Вы не задумываетесь о том, как ток от аккумулятора пошел по цепям внутри электросистемы автомобиля, как начал вращаться стартер вращая маховик, от которого в свою очередь энергия движения передалась на двигатель и пришли в движение его поршни, как от еще не заведенного двигателя заработала система газораспределения т.д. Вы просто повернули ключ в замке зажигания. В нашем случае автомобиль оказался классом, а действие "завести" его методом, Вы же пользователем класса. Вы умеете заводить двигатель, Вы знаете чего ожидать от этого действия (говоря о программировании, Вы знаете, что должен вернуть метод класса, и что нужно ему передать - повернуть ключ в зажигании), этого достаточно для использования класса, и Вам как пользователю не нужно знать как работает класс "внутри" - это так называемая инкапсуляция сложности.
Так же Вам не нужно вручную соединять провода электросистемы автомобиля, Вы просто поворачиваете ключ, а провода соединяет система внутри зажигания, Вы не сможете с помощью ключа соединить провода так, что начнется пожар из-за нарушения энергоснабжения топливной системы, таким образом от Вас сокрыты некоторые данные, говоря о программировании, данные являются приватными и изменить можно только через специальный безопасный метод ("замок зажигания"). Все это и есть инкапсуляция. PHP-программисты не редко отказываются составлять подробную документацию к своим фрейворкам или отдельным классам (я не говорю о готовых работающих системах, речь идет лишь о фреймворках и отдельных классах), заменяя ее документированным кодом класса, это в некоторой степени нарушает принцип инкапсуляции, т.к. чтоб узнать как пользоваться классом, мне необходимо прочесть комментарии к нему, и я не вольно буду читать код класса, что приведет к моим изменениям кода, что в свою очередь возможно приведет к дальнейшей несовмести новых версий класса с системой его использующей. Так же часто все или большая часть членов класса объявляются как public, что тоже противоречит принципам инкапсуляции о сокрытии данных. Вместо этого лучше использовать методы set($a) и get().
Хотя... я сейчас буду немного себе противоречить... язык PHP является интерпретируемым, а это означает, что каждая строка кода разбирается интерпретатором, и куча методов гет и сет в коде + использование интерфейсов (чтоб не составлять документацию отдельно от программы) сильно затруднит работу сервера, что часто заставляет отказываться от строго соблюдения принципов инкапсуляции.

Наследование - это механизм, при котором все свойства и методы класса родителя переходят дочернему классу (классу потомку). Это не сложно объяснить на примере живой природы. Допустим есть класс животное, он определяет общие свойства и методы для всех животных на планете и за ее пределами (касманафты))), животное имеет размер, вес, цвет (иногда не определенный) и методы: оно движется, ест, продолжает род и т.д. От класса Животное мы можем унаследовать класс Хордовые, который будет содержать в себе все свойства и методы класса-родителя + к нему добавятся новые свойства и методы характерные только для этого класса, такие как тип хорды (кость, хрящ, смешанный), место обитания (вода, суша) и т.д.
Таким образом, мы можем через цепочку наследственности классов добраться до определенной породы собаки.
Наследование помогает нам облегчить разработку и сопровождение программы. Так, например, при разработке нового автомобиля, у инженеров одной из приоритетных задач, является использование деталей автомобиля уже разработанных ранее для других моделей, т.к. это серьезно влияет на конечную цену продукта, почему объяснять не стану, думаю это и так понятно, что одна только перенастройка конвейера, изготавливающего инжекторы, обойдется в круглую сумму. В программировании это повторное использование кода.
В PHP с помощью грамотного наследования можно строить очень хорошие, легко сопровождаемые системы, но большие цепочки наследования, могут сильно повлиять на производительность готового продукта.

Полиморфизм - кратко смысл полиморфизма можно выразить фразой: «Один интерфейс, множество методов». Это третий принцип объектно-ориентированного подхода. Возьмем пример с автомобилем (далеко не самый удачный, но из-за не полной поддержки полиморфизма в PHP, другого на ум не приходит*). Допустим, у нас есть класс Автомобиль, при описании этого класса, мы решили идти в ногу со временем и сразу описали коробку передач как автоматическую. Но заказчик решил выпустить спортивную модификацию автомобиля, где использование автоматической коробки недопустимо, мы могли бы переписать класс с учетом новых требований, но можно использовать наследование, где мы переопределим все методы класса, в которых используется коробка передач. Это и есть полиморфизм в PHP (вообще называется перегрузка методов).
Теперь объясню это понятие на примере из языков JAVA и PHP.
Допустим, есть класс MyClass, в котором есть метод summaryAll, который перемножает все переданные ему переменные, а затем складывает их и прибавляет к произведению. Но мы не знаем количество этих переменных, знаем лишь, что их будет не более четырех и у них будет целочисленный тип. В JAVA класс с этим методом можно описать так (это не единственное решение)

Vaska, спасибо хороший и скорый ответ (и почему в мне не попадаются книги с такими примерами)!
Только меня интересует что то более конкретное, а точнее какое превосходство дает ОО-подход по сравнению с процедурным
подходом (желательно с примерами)?

Может потому что я их не пишу?)))

Vaska, спасибо хороший и скорый ответ (и почему в мне не попадаются книги с такими примерами)!
Только меня интересует что то более конкретное, а точнее какое превосходство дает ОО-подход по сравнению с процедурным
подходом (желательно с примерами)?

Vaska, спасибо хороший и скорый ответ (и почему в мне не попадаются книги с такими примерами)!
Только меня интересует что то более конкретное, а точнее какое превосходство дает ОО-подход по сравнению с процедурным
подходом (желательно с примерами)?

Написали один класс (грамотно), используете его в последующих проектах.
Один программист пишет прикладные классы, другой пишет логику используя готовые классы первого прогера.
Сопровождение программы: внесли изменение в одном классе, заменили его в проектах => нет необходимости изменять код в каждом файлике с подобным кодом, т.к. за измененное действие отвечает класс (например, был у вас класс обрабатывающий данные для БД поступающие из разных источников, в зависимости от надежности источника (от админа до поискового бота), вы его использовали в 50 проектах, появилась новая уязвимость, исправили класс, заменили во всех 50 проектах, все. В другом случае вы в каждом файле бы добавляли новую функцию).
Использование фреймворков, я плохо представляю фреймворк написанный процедурно.

Пример кода.. можно выложить "перееханный автобусом и размазанный по дороге процедурный код", а можно грамотный класс на 500 строк... вам какой? первый вариант ни мне ни вам не нравится, второй вариант вы и читать не станете... Посмотрите коды фреймворков..

Сору за флуд....
Во время отсылки сообщения были проблемы с соединением и я повторял попытки....=)))
Со всеми бывает...

Спасибо за внятный ответ.
Теперь пойду искать статьи на эту тему или может вы подкините ссылки на интересные статейки))

2 unlink - вот доходчивая статейка )