A few weeks ago I would have been prepared to answer this more dogmatically, but now I've had experience both ways. You should be able to get the best of both, as the current /Qparallel uses OpenMP in a compatible way behind the scenes. Don't count on that remaining true for future compiler versions. An OpenMP region should prevent the compiler from trying auto-parallel in that region, while auto-parallel could work outside OpenMP regions. So it's a valid strategy to start with /Qparallel and work on regions which need improvement with OpenMP.
My recent case where /Qparallel was more efficient than OpenMP arose where the private list was so big that Intel compiler failed. gnu compiler was able to run correctly but got no advantage from OpenMP. It appears that efficient OpenMP may require careful programming to minimize the number of privates. On the other hand, if you can figure out the optimum way to parallelize with OpenMP, you may do better than /Qparallel. If you organize your code correctly for OpenMP, it may also work better with /Qparallel when you turn off OpenMP.
>>... where the private list was so big that Intel compiler failed.
At this point you should consider encapsulating the body of the loop within a function where the function's local variables are what were the privates. This may mean if your shared list is large, you would have a large number of arguments on the call. (you win some and lose some).
A different tactic would be to create a(two) struct(s) that holds the private (and shared) variables. Instantiate an instance of the struct(s) and PRIVATE/SHARED the container