I think the decision between a single responsive site vs. multiple sites targeting different devices comes down to whether or not you are following LukeW's Mantra of 'design for mobile first'.
If you're designing for mobile first, then it's almost trivial to reconfigure the layout/flow to also accommodate desktop use. There are many other advantage as well...such as mobile forcing you to really focus on the User Experience...paring down the feature set to the core needs of the user. You tend to end up with a much less bloated, much simpler system when focusing on Mobile...which is also a huge benefit for the desktop users.
THEN, if there's still a need for some 'advanced' features for desktop users, there can be an 'add on' set of site features for them.
The biggest advantage to the methodology, IMHO, is all of the future maintenance. You now have ONE code-base. This is an obvious benefit for the dev team, and also a less-obvious benefit for end users (the primary benefit being that there won't be a split between functionality depending on what device they are using).
I think a good example of it being done incorrectly is Flickr. They have a mobile site that's pretty good, but maybe has only 75% of the features one usually needs. So one usually always needs to click on the 'desktop' version. The problem with the desktop version is that it's not optimized for mobile, so there are still things one can't do due to them relying on HOVER or FLASH. It's incredibly frustrating as a user.
I currently work on a project where we maintain the mobile version of a desktop app. Sadly, we have to do this because the desktop app was designed in isolation some many years ago and has such a poor UI, it simply won't work on a mobile device (think dozens of iFrames...ugh).
So, while we're building a pretty good mobile version, it's hard not to cringe at the amount of effort and money being wasted by having to teams maintain two separate code bases for the same system.