I'd like to add to what @Boaz_Orshav wrote.
The installation logic is divided between the DA and to the package itself. the advantage of having a separate DA is that when we find a bug, we don't have to update all the available packages.
Our biggest concern is the offline users, since the online users will always have the updated DA and there are lower chances that they'll encounter an issue. For offline users, even if we did put all the installation logic in the package - if we find a bug a fix it later on, they'd have to replace their package to avoid that bug. This is the same as updating the DA prior to the installation. Checking for a newer package prior to the installation is complicated if you have several packages to install, and especially if you have an internal certification process for each package. Checking for a newer DA is simpler.
As Boaz mentioned - if we do find a bug or a missing feature that is required for a successful package installation prior to its release, we add the fix or the feature to a newer DA, and the package is released with a "minimum DA" value. the package won't allow the installation with an older DA than the set value.
One more thing - I mentioned that each package has a value of a minimum DA needed for its installation, but on top of that, online machines will not allow the installation of any package if there is a newer DA available, until that DA is updated on the machine.