This is not true. GMM is a prime example of this not being the case.
To be more clear: The issue occurs if you are using the application policies to white list software installations, ie you disable all applicatinos at the top level, and then specifically allow your software. The reason for this is an indexing bug with RIM's loader.exe /index progrm. The program generates two XML files, pkgDBcache.xml and specification.pkg. The pkgDBcache.xml contains a hash for each module in the package, and the specification.pkg contains the .cod lcations. The specification.pkg xml file generates correctly, which is why the desktop manger and a simple OTA push work fine. Unfourtunately the pkgDBcache xml file only contains a hash for the .cod that exists in the root, and does not generate a hash for the os specific subfolders.
The result of this is that the BES Policy service will queue up and send down the software to your users devices, once there though, the Application Policy will compare the hash tables and reject the software because it does not match your white list.
BTW, I am talking BES 4.1 here. I have not tested this on 5.0, but I guess the problem is solved there as improvements have been done on app whitelisting and management.