The only part I don't really agree with, is the avoidance of app separation and signals. It's one of the cleanest ways to decouple your modules and keep some level of sanity in a medium-sized codebase. It comes down to deciding what parts really need to depend on others and be very explicit about that.

I generally end up with a few core apps with the main data objects that a lot of other "parallel" ones depend on, a bit "star shaped". And then a few "aggregator" apps that cover functionality that needs to work across multiple of these domains. I see it all as an extension of how you think about your data model.