Modules are units of compilation (well, technically a single function is the smallest unit of compilation) as well as namespaces. It’s just that in most cases, having a lot of submodules doesn’t give you a lot of benefit (as of today, there’s no data hiding like with
private in java).
If the module is useful outside of the current project, making it a package of its own makes sense because then you don’t have to carry around a potentially larger than necessary dependency (think like project C depends on the submodule B of package A - if B is not a package on its own, you’ll have to carry around A as well).
If the module is only useful in the context of the current project, more often than not, building deep dependency chains of modules leads to a lot of A.B.C.D, which vastly hinders readability/reusability.
Note that this doesn’t mean that you shouldn’t use any submodules - if it makes sense to encapsule some functionality in a module, do it! An example I’m thinking of where it could make sense would be a game engine, with a module structure like this:
In those cases, you don’t have a lot of common functionality, it’s not going to be used outside of the engine and parts only interact sparsly, so it can make sense to split it this way. Having a module per struct (which would be the java equivalent) is a bit too verbose though.