Correction

I over-simplified.  Mark pointed out that Group Policy works fine for deploying software installations.  It does, under limited circumstances.

Does it compare with the flexibility, visibility, and recovery capabilities you get with System Center Configuration Manager or even scripting?  No.

If you need to push small packages, like 7-zip, FileZilla, Adobe Flash ActiveX, and things of that scale, it's fine.

If you're pushing to a few dozen computers at a time, or carefully timing your button click to ensure it comes to life during off-peak network utilization, then it can work.

If you don't care to know what fails or goes awry until after it's all done, it can be fine.

If you don't care about uninstalling one thing before installing the new thing, it can be ok.

If you don't care about book-ending the installation (pre-reqs, post-reqs, post-configs, post-cleanup, inventory updates), it can be fine.

If you don't need to touch 20,000 computers in a short time frame, it can be ok.

If the installation packages are all .MSI, or you like shooting heroin and building .ZAP files, or you like making .MSI packages for everything, then it can be fine.

And, yes, there are conditions that meet all of these criteria, and that means using Group Policy is just fine for doing the heavy lifting.  I'm kidding here obviously, but in all seriousness (whatever that means) Group Policy can be fine for deploying software installations.  I'm just saying that I wouldn't ever recommend it as the standard method for doing it.  I would make it the exception rather than the rule.

Thanks to Mark for pointing this out.  In my rush to keep it simple, I went too far in the simple direction and ended up on the short bus.  I will try to be more careful in the future.  Short buses hurt when you walk in front of them.