В чем преимущества ООП ?

Самое важное преимущество ООП - удешевление разработки.

Наследование - НЕ преимущество: цепочки наследования увеличивают хрупкость кода. Например, композиция обеспечивает точно такие же возможности, что и наследование, с куда меньшими проблемами. Что касается С++-подобного ООП, то в большинстве случаев лучше использовать не наследование, а интерфейсы + типажи (trait) - если язык их поддерживает.

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

Тоже приведу пример с БД: на работе в проект с 20-летней историей понадобилось добавить действия, выполняемые при каждом изменении данных в одной из таблиц БД - без использования триггеров. В результате пришлось вносить правки в СТО ВОСЕМЬДЕСЯТ мест в коде - только потому, что работа с этой таблицей была разбросана по всему коду проекта. А был бы ОДИН класс, работающий с этой таблицей, и правки надо было бы внести только в него.

ну, объекты - не панацея, конечно.
никто ж не будет забивать гвозди шуруповёртом.

а преимущества известны: три белых коня - инкапсуляция, наследование и полиморфизм.

Отлично. Работа с БД.
Сколько строк в твоём приложении, сколько раз в них повторяется участок кода, отвечающий за подключение к БД и сколько строк содержит этот участок?

Главное преимущество это хорошая структурированность. Например ты можешь создать класс "пользователь" с основными полями ник логин пароль и т. д. и методами. И каждый раз новом проекте не писать все заново. Если надо что-то добавить то просто используешь наследование.

Другим программистам проще разобраться в твоем коде и менять его.

Когда у тебя будет бизнес логика в 50 000 строк и требование от заказчика её поменять - узнаешь

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

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

Три вехи ооп инкапсуляция, наследование и полиморфизм - так же не могут считаться преимуществами, и частенько становятся недостатками.

Инкапсуляция, как подвид абстракции доступна вообще в любом стиле программирования и на любом языке. Но повсеместное преклонение перед великим ООП приводит к злоупотреблению инкапсуляцией. Как было метко замечено в SICP "Есть одна проблема, которую невозможно решить введя ещё один барьер (слой) абстракции - слишком большое число барьеров абстракции".

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

С полиморфизмом вообще цирк. Под этим названием существуют две совершенно не связанные между собой концепции.

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

Теперь всё чаще под полиморфизмом понимают возможность догрузки или перегрузки части кодовой базы объекта во время исполнения. Т. е. специализацию части коддовой базы в момент применения а не в момент написания. Не нужно быть гением логики, что бы увидеть, что данная штука нарушает принцып инкапсуляции. Мы не должны знать как работает каробочка. Но мы можем изменить её поведение. Кроме прочего, злоупотребление данным видом полиморфизма ещё больше усугубляет проблему 180 мест, где нужно править, ещё больше запутывает код и сложит причиной трудноуловимых багов.