I have no personal experience with DVCS, but from what I gather from the answers here and some linked documents, the most fundamental difference between DVCS and CVCS is the used working model

###DVCS
The working model of DVCS is that you are doing *isolated development*. You are developing your new feature/bugfix in isolation from all other changes until the moment you decide to release it to the rest of the team. Until that time, you can do whatever check-ins you like, because nobody else is going to be bothered with it.

###CVCS
The working model of CVCS (in particular Subversion) is that you are doing *collaborative development*. You are developing your new feature/bugfix in direct collaboration with all the other team members and all changes are immediately available to all.

#Other differences#
Other differences between `svn` and `git`/`hg`, such as revisions vs changesets are incidental. It is very well possible to create a DVCS based on revisions (as Subversion has them) or a CVCS based on changesets (as Git/Mercurial have them).

I am not going to recommend any particular tool, because it mostly depends on the working model that you (and your team) are most comfortable with.  
Personally, I have no problems with working with a CVCS.

 - I have no fear of checking in stuff, as I have no problems getting it into a incomplete, but compilable state.
 - When I experienced merge-hell, it was in situations where it would have occurred in both `svn` and `git`/`hg`. For example, V2 of some software was being maintained by a different team, using a different VCS, while we were developing V3. Occasionally, bugfixes would have to be imported from the V2 VCS to the V3 VCS, which basically meant doing a very large check-in on the V3 VCS (with all bugfixes in a single changeset). I know it was not ideal, but it was a management decision to use different VCS systems.