The main reason: copy errors can always happen, and checking a hash takes a few seconds for most packages. (That being said, I’ve never seen qvm-copy fail to copy a file correctly.)
Now, there is another reason, that is arguably bordering the security theather category. (But remember the assumption that checking the hash takes seconds, so it’s very cheap.)
The reason why data shouldn’t be copied from less trusted qubes to more trusted qubes is that a malicious source qube could send whatever it wants to the destination qube. (It would be a very specific form of compromise, but it’s theoretically possible.)
As a side note, that’s the reason why there are few built-in tools to copy to dom0: as the most trusted qube, there should be few times any data is copied into it. (For further theoretical reference, this model of thinking is called the Biba model - Biba Model - Wikipedia)
In the disposable, copy happens after verification, so theoretically, the data that ends up in the template might not (at all, or only) be the package that was verified.
Performing the verification again in the template allows to detect when a very obviously different package was sent by the dispVM, or an error happened during the copy, which is essentially the same.
If that seems to make sense, why do I think it borders security theather? Because in theory, sending a different package is only one way a malicious source qube could behave. It could also send additional data, that we’re not looking for. Or exploit a bug in the checksum programs… in which case it was better not to have run them in the template, etc. 
In the template, any verification would happen after the copy, and there is no way around that.
Truth is that if you think in terms of Biba model, the moment you copy files from one qube to another, the destination becomes at most as trusted as the source. The moment you decide that you’ll copy the package from the disposable to the template, you’re making the decision to trust the disposable, and to assume that if it was compromised then the verification tools in the template could be as well. What really remains to cover is only the odd copy error which would still be annoying to troubleshoot at installation time and is easy to catch with a checksum.
That’s in theory. In practice, it may be that verifying the checksums in the template most of the time increases the amount of effort needed to compromise it in that way, but honestly we’re splitting hairs at this point and without a concrete risk assessment I don’t think agonizing on this is a useful to way spend much time.
One last thought on trusting the disposable where you downlodaded the package. That’s likeky fine! Unless I’m missing something, it is not that different from what the secure updates mechanism does (it’s not the same, but it’s similar). The main takeaway from the few paragraphs above is how much effort would need to go into a chain of exploits to compromise a template in that way, especially if you’ve only got the time of a download to compromise the disposable qube. Not exposing the template to the internet or to any qube with significant internet exposure goes a long way.
With that in mind, what would I do to take advantage of the disposablility of the dispVM and the tools available in Qubes OS to lower the risk?
- always use a new disposable
- download the package over Tor (implies Whonix disposable)
- not do anything else in that disposable than downloading the file and verifying it (implies the first point, indeed)
- keep the internet / Tor connection open only for as long as necessary to download the package (the NetVM can be removed in the settings while the qube is running, that’s no problem)
I hope this makes sense 