Ok, I can see that my comment about using NOLOCK to fix concurrency issues could be explained a bit better, and that there are legitimate reasons to use it, for example in reporting scenarios.

But I cannot see where I completely condemn the use of NOLOCK. I mentioned that one of our vendors use in in ALL SELECT statements, and most of them has nothing to do with reporting functionality. They are plain SELECTS that returns just a few rows, but because the client app is poorly programmed (as I tried to explain) the have "fixed" it with NOLOCK.