When I make that decision, I primarily consider the data (relations, attributes) and how its being handled (permissions, triggers, functions). User interfaces (menus/forms) can always be changed or extended - migrating data is usually more of a headache the more you do with an application.
For our published apps we worked out that it makes sense for some entites (departments, contacts, locations, ...) to be shared by different apps as they all need the same kind of entities. Its less about whether an app like
Organizations can work on its own, but more about whether entities like
contacts should be owned by a specific app lower down the chain.
If you plan to add more functionality to your app/apps in the future, it might be sensable to place entities that might be shared into
parent apps higher up the chain. Its not about user interfaces, because apps can manage data without having any menu or forms assigned.
In summary: If your data is unlikely to ever be used by other apps you might add in the future - than it makes sense to keep everything in one app (tightly-coupled). If you plan to build on top of your apps in the future, it can make sense for some base entities to be placed outside your app (loosely-coupled), so that you can more easily reuse them.
There can also be other factors in larger organizations, like upgrading a big monolithic app or having split responsibilities for smaller apps between teams. But most are not large enough for that.