Есть ли какие-то недостатки у ООП ? 
Бывает ли, что задача плохо ложится на ООП ? Обязательно ли тем не менее решать ее в рамках парадигмы ООП ? 
Является ли признаком плохого программиста написание программ без использования ООП (или с частичным использованием ООП) ?

Да.


Да. 


Нет.


Нет.

А теперь расширенная версия:   


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


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


Задачу из прошлой цитаты решать с помощью ООП не обязательно и не желательно.


Признаком хорошего программиста является написание программ самым верным путем — простым, быстрым, эффективным. А как именно — дело мастерства. 
Но в любом случае стоит заметить, что программирование — сфера широкая и важную роль играет прикладная область. Как было замечено, есть задачи, решаемые не с помощью ООП. Если прикладная область состоит почти полностью из таких задач, то знание ООП малозначимо.

  Параллельные задачи плохо ложатся на ООП. ООП требует, чтобы состояние объекта менялось скачкообразно при возникновении событий. Если более одного потока "терроризируют" объект, синхронизация доступа может сильно усложнить реализацию, замедлить доступ и приводить к различного рода гонкам и дедлокам. Объекты плохо описывают быстро (непрерывно меняющиеся процессы) , потому как код пишут исходя из предположения, что состояние объекта на определенном участке остается неизменным. Если это не так, то требуется блокировка состояния объекта. Блокировка же объекта может привести к тому, что он перестает отражать актуальное состояние того что он описывает, что в свою очередь может повлечь непредсказуемые последствия ( система занималась бесполезной работой, в то время как пропущено важное событие ). 
  Грубо говоря ООП хорошо работает с гладкими функциями, когда малое возмущение входов порождает малое возмущение на выходах.
  Пример инертности состояния. Пусть есть 3 зависимых объекта объекта A,B,C. состояние объекта в момент времени i обозначим малой буквой. Например ai, а предыдущее состояние ai-1 . xi - входной возмущающий параметр.
Определим зависимости таким образом. 
ai=A(xi,ai-1)
bi=B(ai,bi-1)
ci=C(ai,bi,ci-1)
---------------------------
итерация №1 - x1
Вычисляется состояние объекта А . a1=A(x1,a0) . Состояния B и С неизменные
От объекта А зависят 2 объекта В и С. Генерятся 2 события. 1е для B и 2е для C
---------------------------
итерация №2
Вычисляется состояние одного из объектов B или C
1)Пусть вычисляется сначала B
b2=B(a1,b0) - b1==b0, генерится событие для С (поскольку изменился B)
Объект С остался неизменным с0

2)Пусть вычисляется сначала С
с2=С(a1,b0,c0) с1==с0
Объект B остался неизменным b0
-----------------------------

итерация №3
1) вычисляется событие B->C
c3=C(a1,b2,c0)  или C(A(x1,a0), B(A(x1,a0), b0), c0) 
2) вычисляется событие A->B, затем B->C
b3=B(a1,b0) , b3==b2 - результат как в 1й ветке
с3=С(a1, b2, c2) или C(A(x1,a0), B(A(x1,a0), b0), С(A(x1,a0), b0, c0)) 
------------------------------------

Итого имеем в зависимости от порядка вычисления событий два разных состояния с3
C(A(x1,a0), B(A(x1,a0), b0), c0)  и C(A(x1,a0), B(A(x1,a0), b0), С(A(x1,a0), b0, c0))

На ровном месте получили состояние гонки.  Добиться однозначности можно лишь наложив блокировку на объект С. А теперь, если рассмотреть общий случай, что состояние входа x может меняться на каждой итерации, то для достижения правильного результата потребуется одновременно блокировка и B и С, что приводит в конечном итоге к тому параллельно это вообще не исполниться  .

  Решение этой задачи через функции будет очевидно проще и быстрее.

  

серебряной пули не существует