So, I generally don't see Munki and Puppet as occupying the same space. Munki is package management - it excels at installing and removing packages from your Macs in a way that is most harmonious to your users. It will present a nice GUI window that looks identical to Software Update (so it's very familiar) and allow the user to choose when their updates are installed. You CAN force updates upon users, but Munki's allure is its graceful system-installation set. If you want Munki to manage any other aspects of your computer, then you need to package it up. Wanna make a change? Create a package. At its core it's essentially something similar to Yum or Apt in the Linux world, no? In the same way you can "yum install firefox" you can add Firefox to a Munki manifest and push it to the user.
Puppet is CONFIGURATION MANAGEMENT - so it is focused on an ideal state for your computer. Maybe you want to ensure that this service is always running, or that these config files are ALWAYS identical. Perhaps you need specific local users/groups on your computer - Puppet will ensure that. It also 'speaks' the language of most Linux flavors - so while the Apache service may be called "apache" on Debian or "httpd" on RHEL, Puppet knows how to talk to both of them through its DSL (or domain specific language - essentially, just Puppet Syntax).
The POWER, then, comes from using Puppet to TELL Munki to install a package - right? Well, we're not there YET, but we're working toward that end. Puppet has many package providers (it can install packages using RubyGems, Yum, Apt, Darwinports, Macports, PKGDMG, APPDMG, etc...), but the power in Puppet is that you don't have to REMEMBER how those package providers actually do the gruntwork of installing the package - you can just say package{"firefox": ensure => present} and be on your merry way.
So, to summarize, Puppet is a way to ensure the configuration of your systems and Munki is a way to install packages on your systems.