On a tangent to this, what is the "Linuxy" stuff you don't get to do on OS X? (My own frame of reference being an Ubuntu user.)
Also, OS X is usually behind even compared to Linux distros with fixed releases (i.e. not rolling). You get your basic Unix software in one fell swoop, with the occasional update through a dot version. Apple doesn't provide a pkgsrc or even a rpm/deb packaging system. There are third party efforts, like MacPorts, Fink or – as the author mentioned – Homebrew, which is more similar to BSD's package tree or Arch's AUR (basically a git repo of Ruby build scripts).
Nevertheless, these add on to your system, so aren't really integrated perfectly. Also, compared to Debian or Arch, you'll have a smaller package list (esp. true for Homebrew). So it might just be easier to install some stuff from within a headless Linux VM.
Heck, I've been doing something similar even when I was running Linux as a dev environment. Your deployment environment might be quite different, and I like to do some local testing first – doubly so if your company doesn't even have a proper testing/integration environment. I had an Arch PC, but deployed to both somewhat recent Ubuntu machines and ancient SuSe installations. Now, I often work on OS X and deploy to a CentOS VPS. All good use cases for VMs – and the way described, where it's just a small headless instance in the background instead of a useless GNOME desktop-within-a-desktop is a pretty good approach.
This is really a great overview of why I like this setup, I couldn't have put it more clearly.
An example of something I've been trying lately and didn't work well under OSX: ruby bindings for FUSE filesystems. I wanted to write a quick FUSE fs using ruby, so I installed gems and other dependencies. But since MacFUSE has been deprecated for a while, it's not easy to get everything working.
It could probably work under OSX, but given the current state of FUSE on Lion, I gave up (and did not try it under Linux yet).
While trying to setup my FUSE environment, I installed every FUSE version, many gems with a couple of ruby versions with rvm, rbenv, ruby-build, etc. When playing with new tools and environments, I always end up with lots of useless or broken stuff.
This setup allows me to keep my base system clean and simple.
I do not use it daily, but it's nice to have it ready to launch when needed.
That's one of the reason why I think that every company larger than one person should have a dedicated VM server…
What I still have to try is NFS mounting my Mac's $HOME directory. Introducing some special cases into the shell startup scripts etc. shouldn't be a big deal, but me and NFS had a bit of a tiff a few years ago…
Consider what exactly you'll be using in your stack, and go from there. I've had zero problems over the years using OS X for Rails, Python, node.js, and C++ development that was seeing deployment on Linux (typically Debian or Ubuntu, sometimes CentOS).
Even if you're running Ubuntu 10+ on your laptop (a somewhat more sane assumption), you'd want to test your code on something closer to the "metal".
And honestly, (L)AMP (for normal values of P) won't be a problem on OS X. The usual frontend stack doesn't have major differences, maybe apart from a different default versions of the software (which are easy enough to install). Once you get closer to the system-specific stuff (when it get's more unix-y or network-y), then care about the differences. Not exactly the case for most web scripting stuff…
Then I ran into some problems getting gvim working in that setup. I'm not completely facile with all things Linux and usually Google for some help setting things up, but in this case I couldn't find anyone else who wanted to install gvim on OS X using X11, so I was out of luck there.
In the end I just fired up a Linux VM and it was all as easy as could be.
I'd encourage every Linux developer to get a similar setup with a BSD version – or even just an older and/or different Linux distro.
LXC (obviously).