There are lots of little answers to that question. For instance brew is a third party addition to OS X whereas its equivalents in Linux-land are integrated into the main OS. Brew does a surprisingly good job, but it still has to work around the fact that the main OS wasn't installed with brew.
But there are two big meta-reasons:
The first one is that since much of Open Source in general is done to "scratch ones on itch", Linux can be seen to be "by developers, for developers". This is generally seen as a negative for non-developers, but for developers it is a positive.
The second one is that if you're a web developer, your deployment platform is going to be very similar to your development platform. This means that you only have to deal with half the number of platform specific bugs and configuration. More importantly, you discover these platform specific bugs and configuration issues sooner.
> Your deployment platform is going to be very similar to your development platform.
I'm glad you mentioned this because Sputnik is very awesome for this. They included our new service orchestration tool [Juju](https://juju.ubuntu.com/) (along with a bunch of other useful stuff) on it to do just exactly what you're talking about.
This lets you deploy your application locally on the laptop using LXC containers, assuming you're set up with an environment called "local" and your AWS account called "amazon", hack on your local app, let's say it's node.js, when you're ready to test:
Then just `juju status` gives you a listing of your environment. What happens on Sputnik is you've deployed three [LXC containers](http://lxc.sourceforge.net/), one for orchestration, one for your node app, and one for mongodb with Ubuntu server just like they would deploy on EC2. Then you iterate a few times, commit, deploy, test. After you've done this for a while, now you're ready to deploy in EC2:
Then `juju status`, snag the public URL for your AWS instance, paste it into your browser, and you're deployed.
The nice thing there is you're doing all your app development locally on sputnik in containers that are pure Ubuntu Server, just like you'd get on AWS or HP Cloud, except now you're not running up a bill testing every little thing, you can replicate those kinds of deployments locally, which is nice when you're on a plane.
Sorry to sound like a commercial but Dell lent me a Sputnik to show this off at OSCON and it's really really nice to be able to just fire up deployments locally on a fast SSD and then push willy-nilly to the cloud, all right out of the box.
Totally agree with this post, I make CRUD-dy web apps and my dev box is a mirror of my production stack (nginx, apache, postgres, python/django + associated tools) with the desktop stuff like browsers, chat clients bolted on.
Having a desktop like this means I get to practice all the intricacies of sys-admining (nginx configs etc) just by turning my machine on and running my apps on localhost and it shows when I compare my sysadmin skills to all my peers using MBPs
Don't miss anything from Macbooks except the battery life but I'm on a bootstrapped budget so my beater will have to do until we get enough customers to pay for a new computer.
The big tools like Nginx probably compile on Mac. The edge you'll get from using Linux every day is troubleshooting tiny problems and picking up details about Linux's guts.
Questions like "Is my webserver going to perform well under load?" would be answered if you knew what epoll() was and if your server had it enabled, but you wouldn't really learn that until you messed with it on Linux. Plus it's just fun to tinker with your app's performance and Linux lets you do that in spades.
But there are two big meta-reasons:
The first one is that since much of Open Source in general is done to "scratch ones on itch", Linux can be seen to be "by developers, for developers". This is generally seen as a negative for non-developers, but for developers it is a positive.
The second one is that if you're a web developer, your deployment platform is going to be very similar to your development platform. This means that you only have to deal with half the number of platform specific bugs and configuration. More importantly, you discover these platform specific bugs and configuration issues sooner.