We have battled the "Application Download failed" errors off and on and for a while it was off and now back on.
On our initial t/s efforts and subsequent, albeit, temporary solution, we determined that we had too many boundaries configured ... > 5K, many of them being IP Range boundaries, which is known to be frowned upon. This was due to the Forest Discovery being configured to auto-generate boundaries and even though we didn't have 90% of them assigned to Boundary Groups, this affected the way some stored procs calculated the boundary and content location mechanisms.
Our remediation plan consisted of disabling the auto-boundary creation and doing some cleanup of our boundaries - we got that count down to around 600. In addition to that, we installed SP1/ CU2 (which was the latest available CU at the time) and that included updates to the stored procs to improve the performance and calculations...
the specific stored proc updates that we focused on were:
MP_GetAssignedSite
MP_GetContentDPInfoProtected
MP_GetContentDPInfoUnprotected
MP_GetLocalMPListForSite
MP_GetProxyMPListForSite
MP_GetSiteInfoUnified
After performing the boundary work and applying CU2, we eliminated any Application Download Failed errors.
As far as I know these improvements are also in R2 ( we are on SP1/CU2 still and SP1 alone doesn't have these improvements ).
Fast fwd to now, we are seeing them again and with multiple applications in our task sequence and not consistent at all.
Based on this, we are going to try the suggestion of setting the Download setting for some of the offending apps - even though our boundary group connections are all configured as "Fast", wondering if there is some shenanigans going on from the client/MP side.
Hope some of this helps someone out there.