Double buffering prevents the user from seeing a half painted buffer. Instead of having the application draw directly to the screen buffer, the application draws to an offscreen buffer and the buffers are swapped only after drawing is finished. It's orthogonal to whether you do full or partial updates. (Although if you do partial updates then you're not really swapping the whole buffer, you have to do a blit to present instead and that can actually be less efficient than swapping if the swap path is really swapping, say if you're in fullscreen exclusive mode or if hardware overlays are in use). And it can only ever increase the time it takes updates to reach the screen, not decrease it, since it adds an extra step (swapping) compared to drawing directly on the front buffer.
Why would you draw the entire screen? Well, it instantly eliminates a whole class of bugs where partial updates don't match full updates. It eliminates a ton of really complex code you'd otherwise have to write to track the on-screen size of arbitrary changes separately from painting them, and skip things outside the dirty rectangle while painting. And it doesn't change your worst case performance, which is what you care about when trying to hit a fixed frame rate. Actually the worst case performance should be slightly better because you're not wasting time tracking changes when you have to paint the whole screen anyway.
So the question really is, why would you bother to implement partial updates? The only real reason would be to save power in scenarios where only a small part of the screen is changing. Which is important but not that related to responsiveness or animation smoothness, which again are about worst-case performance.
Even if you do want partial updates you may be better off simply special casing a few common things like blinking cursors or video playback than implementing a fully general change tracking solution.