(a) the problem is somewhat well-defined, and there is a natural 'end' to the exercise. For example, a P0 bug that needs fixing immediately, and there's not much time for additional code-review. In this situation, pairing with the person who knows the area well may be beneficial, because you get code-review while solving the problem. And your non-keyboarding partner can see things that you are too deep in to see.
(b) an interviewing technique to see how you collaborate and approach problem-solving (once again, there's an element of non-open-ended problem-solving here). I must hasten to add that this should not be the sole evaluation method in an interview, because many people can't collaborate impromptu with someone they do not know, and many people prefer to let their minds wander in search of a creative solution, which can look like cluelessness in an interview situation.
(c) inducting a new developer into a team: by watching a veteran at work and the techniques he uses, a new hire can quickly absorb best-practices that will bring his productivity to a high level in a relatively short time period. Once again, this must be done for shorter time-periods: it's pretty much impossible to maintain a high level of engagement with a problem for hours on end. Putting the problem in your back pocket, and sleeping on it often leads to flashes of insight that can deliver robust, clean code (the first system or solution to a problem is almost never the best, particularly in software or schema design).
I can't imagine many other scenarios outside of these, particularly for routine software development work, especially when code review by peers is a mandatory step in the process. You are probably removing the element of slow thinking, which can improve product considerably, by forcing pairing all day, every day.
How does such a wonky culture take root in a fairly large organization anyway? A lot of senior developers would just refuse to work for such an organization!