1. There is a time between the installation of the package and the run of any tool to generate checksums. Things can happen to a file in that time period. Files can even be damaged while being installed by dpkg. One example is a broken hardware writing faulty data to the HD on occasion. Or some breakage in system software etc. There are certainly other scenarios that one can envisioning to cause file changes between the time the package is generated on the maintainers machine at the running of tripwire after the install. md5sums does not have this window of opportunity for file corruption.
Tipwire etc can not guarantee that the files are the same as packages on the *maintainers* system. 2. Tripwire needs to be rerun after a package is installed, removed or changed in any way. Needless to say that this is quite a hassle and takes awhile. The user can easily just forget it doing it after an update of a package. Running tripwire in such a situation will show strange results that might not be easily comprehendable by an average user. With md5sums reruns are not necessary and handling can be made user friendly and easily understandable. 3. Very importantly md5sums covers the integrity of binary files installed. Corruption in config files is usually visible since config files are mostly designed to be readable by humans. The configuration of a malfunctioning package can be checked with an editor. The binaries of such a package can be checked with md5sums.
