One thing that I usually enjoy with Debian is the fact that many software comes the way their upstream author wanted it. KDE is a good example. I must say that, in this regard, I'm quite annoyed with exim 4. While with exim from http://www.exim.org you have one clean flat configuration file, with debian, now (unlike with exim 3.x), you have to deal with tons of small file or one big unreadable file. If you choose to use the unreadable big file, you end up forcing settings at the begin of the file because you do not now how to put them otherwise (and when you are already familiar with exim4 and have a system running, you may not be very interested in learning how this system work). And you have to careful select where you'll put your personal routers and transports between heavy blocks of hashes. Once it is done, your configuration file got migrated, stripped of the comments in /var/lib/exim4 -- a very common place for configuration files. This whole thing seems overcomplicated to me. I always preferred exim over sendmail and postfix because it was damn so easy to setup in an efficient way. But as it is shipped with Debian, it is no longer the case in my opinion; I'm more efficient at recompiling the package directly from upstream, that's not a good sign.
One other funny thing is the fact that instead of using the mail or exim account, exim 4 use a user called Debian-exim. The "Debian" is quite interesting: I am running debian, do I need that to be recalled everything? The default output of ps is now very informative (user = Debian-[squish]), I'll be very happy the day apache will be called Debian-[squish] too. The capitalization of the first letter is nice too: it is the only system account that have it.
I am sure there are many good reasons behind this, even for the strange account naming policy. But I am truly unsatisfied. I have the feeling of running a package that was imported from another distro, an alien package, that obey to a different set of rules than the others.
One thing I value most in Debian is the distinction between stable, testing and unstable. I did not agree with people saying stable should be released for often so it fits for desktop usage. Desktop usage can handle a few bugs and frequent changes but not servers: if people want to use the latest stuff, going to test (or even unstable) should not be a problem. Since two years, I use testing on my own desktops machines/laptop, I never suffered serious package upgrade problems. But now we reach a point where stable is no longer suitable even for servers. If you run a mail server, you'll probably want to have spamassassin, maybe mhonarc and mailman: these software in stable are so outdated that you are likely to start with testing. If you run a webserver, you'll maybe want to test apache 2.0 ; let's go for testing too. If you run a subversion server, you have to go for testing...