Unlike nightning, I hope the answer to the question is always.
On detailed designs
What else do you give in your design deliverable to developer if not a full specced-out design that ideally has be the same one you've used in your user-testing using prototypes?
My experience is that if you leave any stone unturned with your design - ie, any place for interpretation - the developers will come up with all sorts of solutions that can very well be counter-usablity.
And then if you use prototype A.01 in testing but then give design A.05 to the devs, the gap between the two is untested.
No doubt, early prototypes are often scoped to key design challenges, but late ones should, in my view, be as close as possible to the real thing.
Coded prototypes in modern age
In this day and age, where many designs involve an excess of interactions (and animations), functional prototypes become more and more important. Personally, the interactive requirements of some designs mean that spelling these out in a static document makes no sense whatsoever. I find myself sometimes delivering designs with an interactive prototype (an actual website) saying "this is how it should work like" and only spell in the design document things you cannot show (or not obvious) on an interactive prototype (eg, "Sorting by 'active' means by the most recent timestamp of both posts and replies").
Having had my time as a developer, I have recently ditched wireframes altogether and jump straight from excessive sketching to working prototypes using HTML, CSS and AngularJS. The backend is all a stub simulating the real system, but the front end, in quite a few cases at least, can be copied-and-pasted to the actual system.
However, as nightning mentioned, speed is critical for these prototypes, so although the prototype works as expected, its code is fairly dirty in most cases (you don't spend time to code it right, you just need it to work). So some extra refactoring work is often needed.