Debian testing would make a much better choice on the desktop for anyone not actively trying to help Debian development by trying bleeding-edge packages and filing bugs. Run Debian sid if you don't mind encountering breakage and filing bugs, for the benefit of the users of testing who then won't have to deal with the buggy packages you did. :)
These bugs range in severity from "inkscape becoming the default PDF viewer" to "file conflict prevents installing a package" to "libc6 lacks the /lib64 symlink and now no dynamically linked programs on the system can run", and everything in between. Fortunately, the "break the whole system" bugs don't happen often, but still: don't run sid unless you want to help filter out breakage for others by hitting it yourself.
I know that the plural of anecdotes is not data, but I currently run Sid, and I have been for several years. It hasn't been problem free, but I don't recall a system-killing update. The most common problem is some missing or broken dependencies for a package forcing me to hold off installing a package or updating my system for a few days.
In the mean time, back when I used to live with someone who used Ubuntu as his main system, and when I used to run Ubuntu on my laptop, I had to fix system-crippling bugs at least 3 times.
So, anecdotally, I've had less system-killing problems with Sid than Ubuntu's stable releases.
When it comes to system-killing bugs, it also matters whether you update daily or less often; system-killing bugs often get reported right after a mirror pulse and fixed one or two mirror pulses later (less than a day).
Not everyone cares about having the latest bits. Sometimes, you want a system which you don't have to upgrade or fiddle with frequently. And yes, that can include desktop systems, particularly desktop systems other than your own. :)
I run Debian Squeeze on the desktop because I have jobs I want that desktop to do for me, without my having to worry about it unexpectedly not being able to do them.
However, I treat Squeeze more as a base to build on than as a complete system. For instance, I work with Ruby via rvm, not native, and use a Firefox Nightly build. In that sense it makes a rock-solid foundation: anything that I'm not responsible for, works. Anything I am responsible for is my call, and can't break the underlying system unless I try quite hard.
