The compositor in the OS wants to run at a consistent 60 FPS whatever rate your application runs at. If there were a single framebuffer for your application, then you might end up writing to it at the same time the compositor or overlay hardware wants to read from it to put it into the final frame. This would cause tearing. (Tearing could be avoided with a lock, but then the compositor might get stuck waiting for your frame to finish, which would also stop the user using the system GUI to get out of your slow/hanging app.)
This is pretty much the same reason double buffering is used when you're drawing to a monitor directly, just earlier in the pipeline.
This doesn't usually apply for processing within your application, because generally everything has to run at the same rate, and you can't run multiple stages in parallel. Say you draw some 3D stuff and then use a full-screen fragment shader to add some film grain and vignetting. It doesn't help if your full-screen shader can run faster than the 3D work, because you'll just be processing the same intermediate frames again.
I can think of two situations really where it might help. The first is if it's not a post-process but something different, such as if you have a GUI or HUD that you want to run at full frame-rate even if you get frame drops in the main content. (This is the case the OS's window compositor falls into.)
The second is if you can run the multiple stages of your processing pipeline in parallel, e.g. on multiple GPUs. That way, you can start rendering the next 3D frame while the full-screen shader is vignetting your previous frame. You'd have to know your hardware pretty well to split the work appropriately. On something like a gaming PC or graphics workstation that's using SLI to use multiple GPUs, you might find your parallel processing is slower because the workload is unbalanced and one GPU is idling a lot.