Przedszkole to przedszkole.

"Twórz jak najwięcej małych klas"
"Nie twórz ciasnych wiązań między klasami"
"Jeden argument ok, dwa to za dużo, trzy zmień coś"

Boję się dzielić kod na wiele klas bo potem trzeba dostarczyć nowe rozdzielone obiekty do pierwszego. Nie pozwalają tworzyć obiektów wewnątrz metod. Nie pozwalają by konstruktor miał wiele argumentów.

Więc jak mam dostarczyć wydzielone obiekty do pierwszego (pierwotnego, sorry) obiektu by książki były szczęśliwe? W konstruktorze? I to nie będzie ciasne wiązanie?

Przede wszystkim trzeba pamiętać, że wszystkie hasła jakie podałeś, są dosyć... ogólne. We wszystkim trzeba zachować umiar i zdrowy rozsądek. Pokaż kod, który chciałbyś zweryfikować pod kątem zgodności z dobrymi praktykami, będziemy mogli ocenić czy coś wymaga poprawy czy nie.

Dodatkowo powiem że nie ma co na siłę próbwanie wciskać wszystkich Good Practices do swojego kodu jeśli nie był pisany pod tym kątem. Spowoduje to jeszcze większy bajzel.
Lepiej i łatwiej na początek małymi krokami robić refactoring wydzielając coś gdzieś.

Wchodzisz w kod coś zmienić. Jeśli widzisz możliwość małego refactoringu to go zrób.

Nie jestem w trakcie pracy na kodem, czytam książkę i mnie naszła ta myśl. Nie da się generalnie odpowiedzieć na pytanie: Jak poprawnie w klasie użyć (np) 5 różnych obiektów?

Bo rozumiem, że poprawnie byłoby wstrzykiwać instancje jako parametry konstruktora (Dependency Injection), ale tu też książka mówi, że nie ładnie mieć wiele argumentów.

No dobra, na tę chwilę przyjmuję że to zależy od sytuacji i nie da się rzucić generalną poradę.

Wstrzykiwać można też Setter Injection

[PHP] pobierz, plaintext 
$obj->setDependency($dep)
[PHP] pobierz, plaintext 

Jeśli jest to kontroler to tutaj spinasz generalnie wszystko więc ilość zależności może być spora, ale jeśli jakaś klasa biznesowa ma dużo to już nie jest dobry znak.

Zależy też kto rozmumie dużo, dla mnie znośnie to 3-4, dużo to 6

W sensie klasa biznesowa raczej powinna po prostu coś zwracać bez większych kombinacji z innymi klasami, a w kontrolerze żongluję tymi klasami biznesowymi. Tak?

Na takie pytanie można odpowiedzieć jedynie mając kontekst konkretnego przypadku.
I generalnie rzecz biorąc ta książka bardzo dobrze mówi. Co zatem w przypadku, gdy w kontruktorze potrzebowałbym 23 argumentów? Najprawdopodobniej mamy do czynienia ze źle zaprojektowanym obiektem, który próbuje zajmować się zbyt dużą liczbą rzeczy na raz.
Kontrolery to dokładnie takie same klasy jak wszystkie inne. Nie powinny spinać wszystkiego, bo co jest do wszystkiego to jest do niczego. ;-) Z jakiegoś powodu da się w sieci znaleźć "odczucia", że kontrolery to jakieś specjalne klasy - nie, nie są w żaden sposób wyjątkowe.
Wręcz dokładnie odwrotnie. :-) To własnie klasy/metody z części "logiki biznesowej" potrzebują wykonać całą ciężką pracę w programie, więc to w nich znajdziemy sporo zależności. Inną kwestią jest to, że nadal trzeba trzymać się zasady - im mniej zależności tym lepiej.

W skrócie: musiałbyś podać konkrety przypadek do omówienia (code review) nawet w jakimś pseudokodzie, bo tak to będziemy prowadzić akademicki wywdów.