I'm not talking about writing software, so much as I am talking about distributing software. Yes, you can use apt-get to install whatever libraries you need, but you can't guarantee that users are going to have access to the same version as you through their distro's repo, so you have to either statically link the version of each library you wrote the code with, or wait for your software to be picked up by a maintainer for all the common distros out there.

Packages do fix this problem though. You specify dependencies in your target distros package you make, and either you duplicate that dependency graph across distros (bad idea) or you let that distros packagers handle it (good idea).

For example, you can make a deb that works on Debian, Ubuntu, and any of its derivatives with its dependency graph. You can do the same with Fedora. And the Arch ecosystem will just use PKGBUILDs of the rpm or deb to package it themselves.

This only works if you let the distros handle all the work for you. But say you need an Apache version RHEL 6 doesn't have, so now you have to build from source. And now you have to build PHP from source, because now RHEL's PHP package won't run with your new Apache. On Windows, this requires that you run two MSI files and hit okay a few times. On Linux, this means you're compiling everything from source. Linux apps are less portable between distributions than Windows apps are among Windows versions (hell, thanks to WINE a randomly picked Windows app is more likely to run on both Fedora and Ubuntu without modification than an actual Linux app is, the distribution just hides that work from you most of the time).

"will compile with usually zero problems"

Things are a lot better for this in 2014 than they were in 2004 (much less 1994) but I still regularly run into things that need quite a bit of handholding to build.

OS X has good package managers but they aren't as intwined with the os as aptitude or yum, for better or worse. Homebrew and Macports are the most popular package managers.