The original article wants to do exactly that, so it would profit from a better-designed "git push".
Also, Git was never designed for minimalism, but rather for feature-completeness. In contrast, Mercurial was designed with a minimalistic approach (as least in the beginning), so I find it especially strange that Mercurial provides a proper "push" but Git doesn't.
Just because git gives you a method (hooks) to do stupid things doesn't mean they should be built into it. Pushing to a live site (or even just the implied case of pushing into a non-bare repo) is a bad idea. If you want to use hooks (or you own script, or scp, or whatever) to do it you can.
1) "Pushing to a live site is a bad idea."
2) "Pushing into a non-bare repo is a bad idea."
both don't hold.
Regarding 1): It depends on how well-tested the code you're pushing is. Also, conceptually it doesn't matter whether you deploy by pushing to the live system, or by triggering a script on the live system which pulls from the test system. Both achieve exactly the same, so both are equally good or bad. However, the push is more comfortable.
Regarding 2): I have a scenario at home where such a push makes a lot of sense. There is a stationary computer and a laptop, both of which have a common document repository (using Mercurial). Synchronization happens when the laptop is at home. It's just "hg pull -u ; hg push". The laptop needs access to the stationary computer, but not vice versa.
If I avoided the push, I'd have to trigger a script on the stationary computer which in turn pulls from the laptop. Net result: One more script and one more communication channel, i.e. more work and less security.
So please be careful with exaggerated generalizations.
Sorry, I still maintain that pushing to a live site is a bad idea -- and that includes indirectly pushing to it with a auto-triggered script. Deployment should always be a deliberate operation and not related to simply pushing code to a blessed repo.
About (2), the script approach is the right one here. Again, just because you have some case where pushing to a working copy is easier doesn't mean git should make that a feature. Write the script once, problem solved.
Pushing code to the "production repo" is a deliberate operation. Running "git push production" is as explicit as "./deploy-to-production.sh".
Also, nothing against scripting. Mercurial needed a small hook, too. But Git's default push behaviour is not only worthless, it's dangerous and risks unexpected reverts of changesets. I already explained this in: http://news.ycombinator.com/item?id=1158563
Git should either have a sane default implementation, or should refuse to push to non-bare repositories. But its current implementation doesn't make any sense. Providing dangerous defaults because people shouldn't use it anyway? That's plain ignorance.
(However, I agree that automatic deployment is indeed a bad idea, no matter whether it uses push or pull. But that's off-topic.)
Also, Git was never designed for minimalism, but rather for feature-completeness. In contrast, Mercurial was designed with a minimalistic approach (as least in the beginning), so I find it especially strange that Mercurial provides a proper "push" but Git doesn't.