I would argue if it’s a big enough application, then it is. For example, whatever you would put in separate modules might make sense to be separate packages. Especially any kind of separate components of the single application. In particular, I don’t think it’s important that a package has more than one “user” (e.g. a downstream module/package).
Note that the difference betwen packages and modules is pretty small, and in particular separate packages do not have to exist in different git repositories, they do not have to be hosted online, and they do not have to registered in General. The difference is that they aren’t nested (but you can have submodules within a package, and you can extend the functions of one package via methods in another) and need separate Project.toml’s, and if you want to make use of versioning and compat, you need to register them (in your own registry). I think one way to see packages is as independently versioned modules for which there are mechanisms to express dependency relationships and compatability constraints in the stdlib Pkg. In my opinion, they are a provide a great way to have a large scalable codebase (by which I mean able to scale to allow many developers or many components, or a lot of code-- not just scalable to have many users).
I elaborate on some of the tooling and misconceptions about registries and packages in my answer Combining two co-dependent modules into a single program - #18 by ericphanson.