Yes. Sure, there are edge cases where accuracy is not a priority, but they aren't that common. When you're looking for ballpark estimates or grabbing a random row, go nuts. But please don't defend, propose, or implement a policy like thou shalt use NOLOCK on every table reference ever. If you don't think those policies exist, ask around; it's more common than you probably think.

Inaccurate ballparks are one thing, but we definitely don't want to make decisions based on data gathered from a NOLOCK query – we could be making a decision based on information that never existed! For a lot more detail, see:

• Dirty Reads, Permanent Damage

We also don't need to apply NOLOCK hints to solve reader/writer blocking when we're already using RCSI. (We don't get any relief we don't already get from RCSI, we just get all of NOLOCK's baggage.)

Here are some other resources about NOLOCK, with a lot more detail than a vague "thar be dragons" warning…

• Bad habits : Putting NOLOCK everywhere
  I talk about why it's such a bad idea to have the "NOLOCK on every table reference" policy.

• NOLOCK Anomalies, Issues and Inconsistencies
  I demonstrate some of the issues with NOLOCK with real examples.

• NOLOCK Is Bad And You Probably Shouldn’t Use It
• “But NOLOCK Is Okay When My Data Isn’t Changing, Right?”
• Using NOLOCK? Here’s How You’ll Get the Wrong Query Results.
  Brent Ozar shows why NOLOCK is overused but ill-advised.

• The Read Uncommitted Isolation Level
  Paul White talks about real issues here, too, in a longer series on isolation levels.

• Transaction Phenomena – Part 1: The Dirty Read
  Michael J Swart talks about dirty reads here (and read on in the series for other symptoms).

• Understanding Dirty Reads: What NOLOCK Does to Your Queries
  Joey D'Antoni talks about the rare cases where it's ideal to use NOLOCK (and the many scenarios where it's not).

• Avoid using NOLOCK on UPDATE and DELETE statements
  In this tip, I talk about why you should definitely avoid NOLOCK on the target of an update or delete statement, which led to…

• Finding Problematic NOLOCK Patterns – Part 1, Part 2, Part 3, Part 4
  …this series on using TSqlFragmentVisitor to reliably find the pattern UPDATE t ... FROM t WITH (NOLOCK).

So what do I do instead?

Typically, the solution to the "readers blocking everyone" problem is to use read committed snapshot isolation (RCSI). This option isn't free, but if you are querying an Availability Group secondary replica, it's the behavior you're getting anyway. Michael Swart, Kendra Little, Erik Darling, and Paul White discuss some of the ramifications in the following posts:

• How RCSI is the easiest way to reduce blocking (Michael)
• Implementing Snapshot or Read Committed Snapshot Isolation in SQL Server: A Guide (Kendra)
• How to Choose Between RCSI and Snapshot Isolation Levels (Kendra)
• Steps For Getting Rid Of NOLOCK Hints (Erik)
• The SNAPSHOT Isolation Level (Paul)
• Read Committed Snapshot Isolation (Paul)
• Data Modifications under Read Committed Snapshot Isolation (Paul)