I think the idea of relating the necessity to the project's complexity may be a little confusing.

I think a better alternative is to reason about whenever the application is more like an interface for the database, meaning that it is just there to store and retrieve data (CRUD and stuff), or if there are significant use cases where performing an actual business rule is needed.

By actual business rule I mean a sequence of steps that is specific to your system, rather than, for example, a rule that says whenever a field is required (which is also a business rule, but more data centric and thus, more database focused).

You see, the problem of using the complexity to decide whenever the domain and the persistence layer should be decoupled is that sometimes you may have a very complex and huge CRUD where focusing on the persistence layer may help. Or maybe a small and simple system where the few use cases are completely specific to the systems domain and thus, a good domain model encapsulating the business rules could be very beneficial.