Из своего опыта могу сказать, что единственное место, где уместно ООП - это при разработке ГУИ на десктопах (как вы изволили выразиться - при рисовании морд к БД).Как можно ненавидеть ООП. Я как начал изучать ООП, подумал как я раньше без него вообще жил.
А сторонники ооп используют его везде (где надо, а чаще, где не надо).
Недавно от делать нечего просматривал книжку "The Art of Unix Programming". (Хоть я ни разу не юниксоид.)
Вот выдержки оттуда
имхо: золотые слова
а то что я подчеркнул - это то с чем я реально сталкивался в работе, и что меня реально бесит и по сию пору
The OO design concept initially proved valuable in the design of graphics systems, graphical user
interfaces, and certain kinds of simulation. To the surprise and gradual disillusionment of many, it
has proven difficult to demonstrate significant benefits of OO outside those areas.
OO languages make abstraction easy — perhaps too easy. They encourage architectures with thick
glue and elaborate layers. This can be good when the problem domain is truly complex and demands
a lot of abstraction, but it can backfire badly if coders end up doing simple things in complex ways
just because they can.
Object frameworks and object browsers are not a substitute for good design or documentation, but
they often get treated as one. Too many layers destroy transparency: It becomes too difficult to see
down through them and mentally model what the code is actually doing.