Хуже ООП-а может быть только ООП < : o)
Самый главный недостаток такой методики, не в том что у него много кода, а в том что нутро такой программы вывернуто с ног наголову. Приходится привлекать специально обученных хУру чтобы они придумали особенный способ описания боли (архитектура/объектная модель/фреймворк/свой термин) и избавили обезьянок от черезмерных страданий.

Когда поймёте как запихнуть придумку своей программы в это прокурустово ложе, тогда может быть сможете худо бедно использовать методологию ООП. А лучше всего с ООП поможет разобраться ... функциональное программирование, именно разобраться, писать на нём вам не позволит костлявая рука рынка - сдохните с голоду ;) После "просветления" вы будете страдать и есть кактус дальше - добро пожаловать в чудесный мир :D почитать 1 почитать 2

//Типо ООП
$user->delete; // пользователь сам себя убивает - где здравый смысл ???

//Типо функция процедурная
delete($user); // функция убийства выполняет операцию над пользователем - уже логичнее

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

PS. В функциональном программировании, библиотеки и фреймворки народ в свои программки цепляет по каждому чиху легко и без сомнений, а причина одна - в них очень просто разобраться и использовать абсолютно не задумываясь как они устроенны, вопросов изучения сложности просто не возникает.