Może rozgraniczmy na dobry początek to co wynika z języka od tego co wynika ze sposobu w jaki jest używany.
Sama składnia języka powoduje, że trzeba się trochę napisać by cokolwiek napisać. Java jest barokowa z tymi wszystkimi nawiasami, zawijasami i wąsami. W niewielkim stopniu poprawia to wprowadzenie lambd. W tej samej kategorii "siedzą" interfejsy. To, że nikt o nich nie wspominał w tej czy innej książce o OOP nie oznacza, że nie są one OOP. Teoria tworzenia kodu (w tym OOP) ewoluuje i dziś gdy silny nacisk kładzie się na IoC i przerzucenie wiązania obiektów na kontener interfejsy są bardzo fajne.
Kolejnym elementem są DTO, których historia sięga zamierzchłych czasów gdy trzeba było używać interfejsu Serializable na potrzeby Hibernate czy serializacji do XML. To powodowało, że do niektórych pól klasy należało dodać słówko transient, co powodowało, że trzeba było pisać własne metody do serializacji i deserializacji (by tworzyć poprawne obiekty) co w efekcie powodowało, że napisanie prostego DTO było szybsze i łatwiejsze. Zresztą i tu mamy "zonk" z serialVersionUID, który nie doczekał się żadnego rozsądnego mechanizmu pozwalającego na automatyzację zarządzania wersjami klasy.
@vpiotr, a twoje pytania dotyczą sposobu korzystania z języka.
ad 1. Jest to przejaw nie tyle co lenistwa, co podejścia "jakoś(ć) to będzie" i tworzenia kodu "good enough", czyli zaspokajania potrzeb biznesowych, a nie technicznych. Obecnie w projekcie odpuściłem sobie sonara, bo nie miałem siły walczyć z ludźmi o to by przed mergem przepuszczali kod przez sonara i starali się eliminować największe babole.
ad 2. Tu odpowiedzialność jest pomiędzy językiem, a człowiekiem. Czasami język nie pozwala na tworzenie wizualnie krótkich metod ponieważ np. wymagana jest odpowiednia obsługa wyjątków (np. kilka różnych klas, dla których wspólna nad klasa to Exception). Z drugiej strony niektóre operacje np. na danych są z natury długie np. ręczne transformowanie obiektów z jednej domeny do innej. Tu skrócenie kodu czasami jest bardzo trudne i wymaga wprowadzenia niepotrzebnych komplikacji np. całej gamy konwerterów.
Jednak, to są nieliczne przypadki. Zazwyczaj długość metody zależy od tego jak programista myśli o operacji, którą metoda reprezentuje, czy jest to operacja atomowa, czy też kompozycja kilku kroków.