Вот с этим - не согласен!
Лучше не доводить до того, что управлять уже неудобно. Потому что переделывать всегда сложнее, чем делать изначально правильно. Да и желания как-то обычно не возникает переделывать сотни и тысячи строк кода
Именно поэтому я и сказал чуть ранее, что надо изучать ООП. Потому что когда знаешь, то заранее поймешь, что в определенных местах надо применить объекты. И структура проекта будет более оптимальной.

Я бы все-таки предложил lawbreader поупражняться с ООП.

Вот смотри, например. Делаешь ты форум. Можно сделать так, чтобы каждый ответ был одним объектом. В нем будут содержаться как собственно ответ, так и информация о пользователе, и дата-время, и всё, что ты захочешь. Для страницы ты набираешь массив этих объектов, и далее ты можешь ими распоряжаться как хочешь. И располагать в любом порядке, и много чего другого делать более удобно, так, как ты хочешь. И будет это легко и просто.
Если это делать как набор массивов, то ты с самого начала будешь пытаться ими управлять (в частности, чтобы данные менять-добавлять синхронно), но периодически у тебя будут возникать проблемы.

Ну это совсем не факт, что правильно. Писать класс, когда метод будет вызван единожды никакого смысла нет. К тому же код при ООП особой прозрачностью не отличается. Вполне достаточно простых функций. Viking же написал:

То есть переделка не подразумевалась. А писать все подряд с ООП тож самое, что стрелять из пушки по воробъям.

Не согласен с каждым из процитированных предложений
Начнем с последнего.
Что значит "достаточно простых функций"? ООП - это не только функции, но структурированные данные. Которые собрали в одном месте, и мы можем, например, передавать их куда-то достаточно легко - это же один объект, одна переменная!
Далее. Насколько "прозрачный" будет код при ООП, зависит от программера, а не от понятия "ООП".
И теперь что касается "единожды вызвать метод - нету смысла". Это с какого боку посмотреть... Вот, живой пример. Есть у меня класс для работы с CSV-файлами. Там данные грузятся в ассоциативные массивы, где ключи берутся из первой строки файла (есть и отдельное описание этих ключей). То есть, класс содержит и данные, и функцию загрузки. Которая вызывается сколько раз? Правильно, один раз! Но смысл в таком классе очень большой. Он описан в отдельном файле, который просто инклудится к тем скриптам, где он нужен. И я работаю с CSV всегда однотипно, и причем так, как мне удобно.
И таких примеров можно привести немало.

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

Ну это уже в контексте этого высказывания:

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

Вот за что я ООП и недолюбливаю. За однотипность мышления.

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

Тогда становится понятно твоё отношение к ООП А я в Си привык к тому, что ООП - это гуд, и использую в ПХП, когда надо. В частности, например, чтобы не создавать наборы массивов для сложных данных.

Насчет "золотой середины" согласен , собственно, я об этом в этой же теме ранее уже говорил.
А насчет скорости работы... Я думаю, что не стоит даже и мгновение об этом думать. Потому что будет скрипт обрабатывать интерпретатором 0,0001 сек или даже в 10 раз дольше... Разница есть для конечного пользователя?????

почему не работает? А кто его знает... ищи свищи этот метод, если не известно даже где класс находится. А когда найдешь, там окажется что нибудь типа

Когда сам пишешь, терпимо. А в чужом разбираться бррррр... Так что по прозрачности тут спорить не стоит.
Все хорошо на своем месте.