Most PHP projects hardcode their ID generation strategy. Calls to Uuid::uuid4() are scattered across handlers, entities, and tests. When you need to switch to UUID v7 for chronological sorting or ULID for shorter URLs, you end up modifying dozens of files - and hoping you found them all.
Mocking a repository in tests does not verify your query; it only verifies that the method was called. Run a real database instead and the test suite slows to a crawl, so you run it less often. Either way, your filter logic ends up duplicated: once in the production code that hits the database, once in the mocks that bypass it. The two drift apart silently until a bug ships to production.
PHP does not have generics. A method that returns array gives no compile-time guarantee about what the array contains. PHPDoc annotations like @return array<Book> help static analysers, but they are invisible at runtime. A wrong element slips in, and the error surfaces far from the insertion point.
It is a common reflex: you start a project and rush into technical choices. PostgreSQL or MySQL? Docker or local database? Schemas, migrations, connections... Meanwhile, the real value of the project, the business logic, waits patiently for its turn.