NOLOCK is NOT a bad thing when used properly, i.e., dirty reads are acceptable for that query (or you know that dirty reads aren't going to recur). There has been a valid war against NOLOCK everywhere; there has been not so valid war against NOLOCK anywhere.
People need to be made aware that phantom reads and non-repeatable reads can occur with READ COMMITTED locking as well. Schema locks are also, IIRC, taken for ANY SELECT, not just those with NOLOCK.
Thus, the only real issue is dirty reads. So, again, if dirty reads would cause you a problem, DON'T use NOLOCK. If not, you can consider it.
NOLOCK is especially useful on extremely static data, such as historical data. I can't imagine any reason not to specify NOLOCK for data that's guaranteed to remain static. For example, we have a table of state abbrevs with name to do lookups. NOLOCK seems obvious there. Similarly, we have tables that are only modified once a week, so NOLOCK for those too.
Allocation order scans could cause issues to be more prevalent with NOLOCK. If you really must you can avoid that by temporarily modifying the cursor threshold setting (ref: https://www.sqlperformance.com/2015/01/t-sql-queries/allocation-order-scans).
But back now to the original reason to use NOLOCK in the first place:
NOLOCK avoids taking locks, which IS more efficient than taking locks. That's kinda self-explanatory, really, right?
Thus, yes, use CAUTION and understand the risks of NOLOCK. But don't automatically refuse to use it or "overblow" the dangers.
One alternative, SNAPSHOT, has wonderfully less blocking. But the overhead of SNAPSHOT is quite high. For example, the potentially heavy use of tempdb and the certain 14 overhead bytes added to each table row. [Perhaps even worse, those bytes are removed when a table REBUILD is done -- meaning that if a rebuilt row is UPDATEd, the 14 bytes are added again, possibly causing a page split.]
SNAPSHOT also has a hidden downside. You see data as from the start time of the query, period. If someone runs a report at 9:03AM that takes 3 hrs, do they really not want to see any later data on the report? Sometimes the answer to that q is not as easy as you might think.
That said, I do have dbs with READ_COMMITTED_SNAPSHOT ON. SNAPSHOT isn't inherently bad, any more than NOLOCK is inherently bad.
As we know, overall database performance is complex and involves many interrelated things.
SQL DBA,SQL Server MVP(07, 08, 09) Prosecutor James Blackburn, in closing argument in the Fatal Vision murders trial: "If in the future, you should cry a tear, cry one for them [the murder victims]. If in the future, you should say a prayer, say one for them. And if in the future, you should light a candle, light one for them."