The ports system is markedly inferior IMO to Debian / Ubuntu's package collection: no real stable tree, build from source, tweaking options at build time is encouraged. This is a moot point for things you were going to build from source anyway.
Niche pieces of software are absent; valgrind for FreeBSD is a fork that doesn't support amd64 last time I checked.
There are less people out there running the exact same application binary + underlying OS as you, which means you're less likely to find people who've had (and solved) the same issue as you.
Using it for your desktop is a bit masochistic. Widespread virtualisation means this isn't really an issue anymore - you can have a VM that mirrors your production setup.
We're still using FreeBSD and aren't likely to change anytime soon. I agree with everything aristus said.
I disagree on the ports part. I like it much better than any other package management system I've tried. For most common apps you can get a pre-built package with 'pkg_add -r'. They really stepped up their game when they embraced portsnap and let cvsup ride off into the sunset.
And if you need something special and/or exotic it isn't really that hard to build from scratch. I can guarantee 90% of the dependencies can be installed as a pre-built package.
The up-to-date bit is my main issue. AFAIK the FreeBSD ports tree is never forked into a release branch which receives security updates and nothing else. And you'll find randomly broken stuff from time to time.
Pros
Stability & performance are noticeably better. BSD's virtual memory system doesn't leave tons of pages in the Inactive bucket. The TCP stack is the best of class, and the UFS2 filesystem rocks the house. Jails have been in BSD more than a decade and don't waste so much $#$@ memory compared to virtual systems. Performance under heavy load is much much better.
Cons: SMP and 64-bit support. :( Linux is the Golden Child for new hardware, so BSD lags behind. I remember panicking my 5.1 kernel with a USB drive, as late as 2004.
64 bit support on FreeBSD is pretty good; the only real issue is being able to compile for 32 bit targets on a 64 bit host out of the box. The ULE scheduler improves SMP support considerably.
On the non-Linux front, Joyent's accelerators (on-demand scaling via virtualization) use OpenSolaris, with the virtualization being provided by grid containers (virtualized userspace on a shared kernel).
Joyent have a good reputation but I'm not a fan of Solaris ancient userspace tools - something as simple as checking the size of a disk is made complex by Solaris not bothering to include an 'h' option - so you have to count your terabytes of disk in kilobytes.
The Solaris filesystem layout is non-FHS and a rather odd mess, with binaries in var and etc, and variable files in usr.
I've deployed FreeBSD and OpenBSD as both front facing and back end systems. My only complaint has been lack of SMP support (to be fixed with FreeBSD7.0 at least, I'm not sure about OpenBSD).
People often complain about Ports but you soon get used to it and I've found the port maintainers to be helpful on the odd occasion when there has been a problem.
Although hardware support can be said to be weak, when choosing servers there aren't a lot of chip sets out there so things are mostly covered. Certainly when deploying to HP or Dell boxes I have had no problems. It only takes a few minutes to check h/w compatibility lists. Chosing the correct servers for any job requires careful research anyway.
The most annoying thing is explaining to people that although it's open, it's not Linux and yes it is production ready.
FreeBSD was my first choice, until I realized that the text-to-speech s/w only ran on linux. There is a linux compatibility mode for BSD, but I'd rather avoid an extra layer of complexity. So our server is running Ubuntu right now.
You should still test BSD...we've actually had Linux software run FASTER in linux compat mode on BSD than on native Linux. It really depends on the software in question...
We're moving from CentOS/Ubuntu to FreeBSD for all our *nix boxes. The decision was motivated by hatred acquired for CentOS over time and the fact our systems administrator is most familiar with FreeBSD.
Niche pieces of software are absent; valgrind for FreeBSD is a fork that doesn't support amd64 last time I checked.
There are less people out there running the exact same application binary + underlying OS as you, which means you're less likely to find people who've had (and solved) the same issue as you.
Using it for your desktop is a bit masochistic. Widespread virtualisation means this isn't really an issue anymore - you can have a VM that mirrors your production setup.
We're still using FreeBSD and aren't likely to change anytime soon. I agree with everything aristus said.