In typical operation, there usually is little reason to worry about QueryInterface calls being cached.
However, other parties may create components where the number of outstanding interfaces is tied to the operation of the component. In addition, there are also outliers where the interface received from a COM object has an implementation that may make it tougher to control the lifetime of the object.
For example, components written in ATL may be created with tearoff interfaces. These tearoffs are not available in the binary layout of the main object, and are typically implemented on another hidden object that coordinates with its parent. Since a successful QueryInterface call implicitly counts as an AddRef call, the lifetime of the tearoff provider may be extended past its intended release if the interface reference is cached. Also, there may also be a case where an object only provides one tearoff of a particular interface with the intent that there is only one consumer at a time through that interface. A cached copy could violate that behavior if two consumers are issued the same copy when the intent is for the second request to fail.
Finally, a more likely scenario is the possibility that each QueryInterface call is being tracked for debugging or logging purposes. Being able to turn off caching may allow someone to diagnose issues where occurrences could be delayed with it on.
Here are some links on tearoff interfaces for your reference.
ATL Tear-Off Interfaces @ CodeGuru
CComTearOffObject Class @ MSDN