a) wtedy kiedy chcemy aby było profesjonalnie
raczej przestarzale, jak chcesz iść w "profesjonalny" wygląd kodu to lepiej celować w programowanie funkcyjne
b) wtedy kiedy nad aplikacją pracuje więcej osób
to brzmi jak jakiś argument... ale nie do końca, programowanie obiektowe z góry zakłada dzielenie projektu na niezależne moduły, co jest niezbędnym elementem jeśli chcemy żeby projekt był przejrzysty i łatwy do rozwijania, ale nie musisz używać programowania obiektowego, żeby podzielić projekt na moduły
c) wtedy kiedy robimy dużą aplikacje
gdybyśmy się cofnęli w czasie tak z 20 lat, minimum kilkanaście, to byłby to jakiś argument
Najmądrzej jest się nauczyć po prostu różnych elementów języka, obecnie każdy ma dużo mechanizmów zaczerpniętych z różnych podejść - i mieszać je ze sobą, sprawdzać co się sprawdza w którym przypadku. Unikaj nastawienia że całą aplikacje piszesz typowo obiektowo, bo skończysz z projektem wyglądającym jakby ktoś go pisał 20 lat temu. Unikaj nastawienia że obiektowość jest zła i trzeba pisać funkcyjnie bo to jest teraz modne, bo będziesz się męczyć z wymyślaniem dziwnych obejść do problemów, które można łatwo rozwiązać innym stylem
Unikaj też nastawienia że cała aplikacja musi być napisana w taki sam sposób - warto trzymać się ogólnych zasad i wskazówek, ale zazwyczaj zbyt restrykcyjne dbanie o każdą linię kodu prowadzi do nadmiarowego i nieczytelnego kodu (bo mogłeś zrobić coś prosto, ale przez jakąś zasade musiałeś skomplikować rozwiązanie)
A tak z ciekawości, z jakich źródeł się uczyłeś, że wyciągnąłeś takie wnioski? Bo śmierdzi mi to starymi książkami na studia