If you develop smaller, modular, "component" Applications every ruleset in that application should be inter-related.  If not, why include it?  In that situation it makes sense to use Application Validation mode.

It also makes sense to use Application Validation mode for your "production" Application. It is the production application, after all; the rulesets are inter-related from the respect.

Still, you should avoid creating unnecessary dependencies between case types at the production Application level as that would hinder your ability to convert one or more case types in the future to a separate modular application that can be built-on. This is why creating each case type in its own ruleset is beneficial,  as opposed to creating cases in the ruleset that ideally would be used only for the Application rule, Data classes, and the work pool class. 

Another way to avoid dependencies is to have cases reference a base Data class defined at the Enterprise layer. Using DCR, the Data class can be changed to your Application's Data class at run-time.  We see this mistake a lot. If you define generic data classes at your Application's level and not the Enterprise level, how would some other Application leverage those generic data classes?

If you define an Enterprise Application, that every other application build on, you can have that Enterprise Application use ruleset validation, validating against the Pega Application versions it is built on, for example PegaRULES 8.