For rendering I have a current GL context associated with a window. In the case where the application renders multiple scenes (for example using accumulation or different viewpo
In GUI programs you can have multiple opengl views, where some of them run in the same thread as the GUI and others run in their own thread. Further more you can run opengl in offscreen mode. At least one context per thread.
Not sure if it makes sense to have more contexts per thread.
I usually tend to use additional contexts only when I absolutely have to, such as rendering to multiple GUI windows. For everything else, I use framebuffer objects or state changes.
However, performance recommendations like this do not apply to all cases. If in doubt, you should measure your own application on your own hardware. gDEBugger might help, there's a trial version available.
If you want to address multiple GPU's, you need to use multiple context since you have at least one drawable per GPU, with a GPU-specific context.
IIRC, objects like textures and buffer objects can be shared between contexts, so technically you could create a second context in a second thread and load the textures asynchronously there, without worrying whether the first thread is performing the rendering.