As a Debian Developer I often find myself throwing away the upstream Debian packaging and starting from scratch. It's not that it doesn't work but that it doesn't fit with Debian policy and so is not easily included or modified without basically starting from scratch anyway.
In the cases (which happens more than you might think) where an upstream developer has actually got really good packaging, I've usually taken the approach of tidying up the last few details and committing back and then mentoring them for a while with them doing the majority of the work and I just double check and upload it.
The level to which people are willing to work on it varies from accepting patches that affect the distribution package version (e.g. hardcoded paths or porting issues) to actually doing the packaging.
MongoDB's Debian packaging is very different from Debian's own packaging. The MongoDB people decided almost a year ago that Debian users only get to use one init/rc system each for Debian 7 and Debian 8.
Also, upstream may have different concerns. For example, they want to be built on various versions of the distribution while Debian will usually only target unstable.
I am upstream for some of my packages and I don't provide the same debian/ directory upstream as I use for Debian.
Now that we have faster moving packages and especially where we have packages that depend on external systems (like cloud services), I think more and more Debian Developers need to be making use of backports to ensure that stable versions remain up to date.
I've heard time and time again that there are issues with Debian's version being out of date, but this doesn't have to be this way, at least not by policy. If there is a backport maintainer (doesn't even have to be the same person working on unstable) then the latest version can be installable within a stable system giving you the latest and greatest of the applications that need it with a stable base underneath.
