Coming from a user of both Linux and both FreeBSD and NetBSD, I can't agree with the absolutes of your post.
BSDs are never easier than Linux. Linux is more modern, while BSDs stick to "tradition" and take pride in keeping things complicated. Just read their manuals/handbooks and you will have a pretty good idea.
An alternate wording: "Linux engages in constant superfluous redesign, while BSDs stick to conventional but consistent, stable interfaces that are well documented". The fact that up-to-date man pages and well-written manuals/guides exist says a lot by itself. Linux's myriad of ever-obsolete HOW-TOs is a poor substitute.
One good example of a painful process in Linux that is easy in (Net)BSD is developing for embedded architectures. I can be typing away on, say, a (PPC) Mac or a (Intel) Linux or a (Sparc) BSD box, and can cross-compile a NetBSD distribution for an ARM single-board-computer with one line: ./build.sh -u -m evbarm release. I could replace 'evbarm' with 'alpha' or 'sparc64' or 'i386' or even 'vax' (!) and I would magically get a system built for these very different architectures, constructed from whatever system I want, all built from the very same code! I didn't have to rely on some vendor to package the cross-compiler or (very painfully) do it myself -- it's just a part of the basic NetBSD system. They got a lot of stuff right!
While I do agree -- "Desktop BSD" is still not where it should be for the traditional BSDs, Linux has a long way to go here too. However, PC-BSD has done a pretty good job of doing the basic grunt work that is otherwise sorely lacking. "PC-BSD is to FreeBSD, what Ubuntu is to Debian".
Your third partition on Linux will be /dev/sda3, but on BSD it will be /dev/ad0s3e (note that it numbers disks from 0 but slices from 1, and there is still the letter "e" for the partition inside the slice - isn't that simple?)
This is a red herring. (1) On my NetBSD system, the first disk is /dev/wd0a. That's not any different than Linux's /dev/sda0. (2) Who cares? Mac OS X shows my root file system as /dev/disk0s2, and you don't see everyone complaining that OS X isn't ready for the desktop! And sometimes the extra information can save your butt. Example: I have an old Sun workstation with 3 SCSI disks that has run Linux, BSD and Solaris at different points in its life. One of the more painful moments I experienced w/ this box was under Linux, when I removed a nonessential disk (mounted as /data) after removing its entry in /etc/fstab and unplugging it. I restarted the system -- and it would no longer boot -- because the /dev entries (/dev/sda, sdb, sdc, etc.) are enumerated in ad-hoc fashion, had reordered themselves, and the root drive was no longer where init thought it should be. In BSD and Solaris, the verbose naming corresponded to their physical locations on the SCSI bus, so you could pull a nonessential disk and it would still 'just work'. That prevented a ton of headaches.
These issues have been solved in Linux with unique UUID's, but now your entry for /dev/sda3 might instead say something like "UUID=1924d0d6-496d-4bbf-8fd1-aaaac6764bc5" in /etc/fstab. Good luck parsing the UUID to mean "3rd partition" unless your fstab file is well-commented! That makes BSD look positively friendly by comparison.
FreeBSD advocates spent a good portion of their time claiming that FreeBSD is faster than Linux. Maybe on servers under very heavy load. In all the tests I have made on a simple desktop, FreeBSD always felt a little bit slow, jerky, worse than Linux with a lightweight window manager such as LXDE (but not worse than Linux with KDE 4, for example).
You're confusing "faster" for "feels faster for interactive use". With all of the scheduler work in Linux over the past year or two, Linux desktop interactivity is really excellent. However, there is always a compromise between interactivity and overall throughput. BSDs schedulers tend to favor the latter, for better or worse.
NetBSD feels very light and fast, but then it doesn't do much out of the box. If you ever try Tiny Core Linux, check what it can do out of the box, that's about 18 times as much as what NetBSD can do.
This comparison makes no sense (to me) whatsoever. Stock NetBSD provides the loose equivalent of "Debian base+Xorg+gcc", and you can install whatever packages (binary or source) you want after that. Full versions of everything. Like Debian, that's not really comparable at all to Tiny Core Linux -- while it's a VERY cool project, it provides no compiler, very minimal command line packages, only a fraction of Xorg, a minimal GUI, and is i386/amd64 only. Under (Net)BSD, I'm just a 'pkg_add' away from having, say, Firefox, XFCE, etc. installed -- and with few exceptions, the process is *exactly* the same on Alpha, Sparc(64), Intel/AMD64, or ARM. Different targets.