If by 'almost anything' you mean 'some, mostly using node.js or ruby', then yes. Otherwise, no. For example, Docker has to run a Linux VM underneath to just work.
Both linux and macos have different strengths and weaknesses, and one is not a fully capable replacement of another, not even just for the cli/daemon stuff.
I'm writing this on a rMBP - and there are still reasons to ssh into a centos box.
Docker is an extreme example. Of course things relying on Linux-only kernel features are unlikely to run natively. You'll find plenty of compiled stuff on OSX (wkhtmltopdf, freeciv, postgres, inkscape, clojure, etc., etc.).
I know, I run postgis+mapnik on OSX. It is quite PITA to build, postgres clients usually link against wrong (system-supplied & ancient) libpq[1], everything links against wrong (system-supplied & ancient) zlib, half the things link against wrong (system-supplied & ancient; see the pattern?) sqlite, etc. Yes, it is problem with the build scripts, but I don't have an ambition to fix all the packages, and Linux packages do not have this problem. Actually, they have usable and maintained binaries just a single yum command away, so you are up and running in no time, compared to solving build env problems in OSX.
[1] - /usr/lib/libpq.dylib is especially annoying offender. Most dylibs are at least fat ones, but this one is x86_64 only. That means, when you want to build a fat binary of some libpq client, and it is being linked against system one, the build will fail. That includes building i386/fat version of postgresql itself.
Both linux and macos have different strengths and weaknesses, and one is not a fully capable replacement of another, not even just for the cli/daemon stuff.
I'm writing this on a rMBP - and there are still reasons to ssh into a centos box.