To answer your specific question, and focussing on two recent OpenGL titles:
- A frame of Doom 3 BFG Edition can use ~12 different GLSL programs.
- A frame of Rage can use ~38 different GLSL programs.
(Captured using GL Intercept).
So the answer is a "yes" - OpenGL games (or at least these ones) will use multiple shaders.
As a general case answer it's more a case of "it depends". The choice to use multiple shaders or using branching can often be down to which is the more expensive option - making a shader change or having every vertex or fragment processed have to take a branch.
In the old days this was pretty clear cut - the first shading languages available didn't support branching at all, so you had no option - you used multiple shaders.
As branching support started coming in, things got interesting. First off, you might want to support older hardware, in which case you likewise didn't have a choice - no branching. Secondly, the original forms of shader branching were quite primitive; basically both branches would be executed and the internal hardware registers would be updated based on which one passed (i.e. branching was most likely just emulated using a mix/lerp/step/etc instruction - you can still see this today in HLSL code if you compile with branching disabled and view it's disassembly). So again the best option was to not branch.
Modern hardware is, of course, more flexible and you have 2 forms of branching available. Branching based on a shader uniform (GLSL) or constant (HLSL) should be very cheap indeed - not free, but the hardware can know that all executions of the shader for the current set of states will take the same branch, and optimize accordingly.
Branching based on some value determined at runtime (or input via a vertex attrib) is more interesting. Modern hardware will execute shaders in "groups" (I'm avoiding vendor-specific terminology here) of vertices or fragments, and if all executions of a shader for a given "group" take the same branch, it can also pull some optimizatios.
There's also the fact that GLSL complicates things a little by having current uniform values be part of program state. HLSL doesn't have this, and it's not the way hardware works, but that's the decision that was made for GLSL, so what it means is that a shader change could also involve saving out the existing contents of hardware registers, then loading in new values as part of the new program state. Using UBOs would also avoid that, of course, but if you're using standalone uniforms then you need to be aware that changing shaders can involve a good deal more than just swapping out some small executable images.
None of this is to say that having a single big shader with lots of branching is the preferred option, of course. Branching still has it's own cost, and it may well incur more overhead than a shader change, even on modern hardware. You also need to consider that your vertex shader input is quite tied to the shader itself, unless you use a common vertex format and layout for everything. On modern hardware with geometry and tesselation shader stages you may have to deal with cases where these (optional) shader stages may or may not be active in the current program. Beware especially of the geometry shader, because it can be sloooooow - even if just a passthrough shader - so you'll not want it active unless you're doing something that explicitly requires it (such as writing to a non-zero viewport index).
So all this lengthy preamble was a fairly roundabout way of coming to the usual conclusion to questions such as this: everybody's use case is different, so profile, benchmark, find which is the fastest for you, decide which performance vs flexibility/code-cleanliness tradeoffs you will or won't accept, and base your code around these real-world metrics.