There are three fields of application for Lintian:
one person could use Lintian to check the whole Debian archive and reports bugs,
each maintainer runs Lintian over her packages before uploading them,
dinstall checks packages which are uploaded to master before they are installed in the archive.
The authors of Lintian decided to use a very modular design to achieve the following goals:
flexibility: Lintian can be used to check single packages or the whole archive and to report and keep track of bug reports, etc.
completeness: Lintian will eventually include checks for (nearly) everything that can be checked mechanically.
uptodateness: Lintian will be updated whenever policy is changed.
performance: Lintian should make it possible to check single packages within seconds or check the full archive within a few hours.
The design also has a number of constrains that limits the things Lintian can check for and what tools it can use:
static analysis: The code in a package may be analyzed, but it should never be executed. However, Lintian can (and does) use external tools to analyze files in the package.
deterministic replay-ability: Checks should not rely on the state of system caches or even the system time. These things makes it harder for others to reproduce (the absence of) tags.
same source analysis: Lintian checks packages in small isolated groups based on the source package. Requiring the presence of all the dependencies to provide the full results make it harder to run lintian (not to mention, it makes "deterministic replay-ability" a lot harder as well).