The (NOLOCK) optimizer hint is well known by most SQL developers for setting the isolation level so that tables with rows or escalated page locks can be read. I've always known about the bad and ugly; dirty reads, errors, dup rows that can occur. My specific question is why is it so overused in every organization I tend to consult with? I've seen it used for every select statement on every table in the last 3 clients I've been at. These are OLTP systems and not replicated data that is read only. What are the possible reasons for this? Is the memory/hardware insufficient to get transactions processed? Is data consistency less important than it used to be? What is the general consensus and best practice on using NOLOCK? 
Use of NOLOCK on Microsoft SQL Server
sql;microsoft
You seem to already know what the table hint NOLOCK does, but you question why do people use it so frequently.  In people's experience, or people that have shared experience with them, they have alleviated concurrency problems before by using the read uncommitted table hint.Despite what the hint does (the lack of issuing a shared lock on data to prevent from blocking or being blocked), they still use it.  Why?  Because it is easy to sacrifice important things (consistent and clean data, security, etc.) with common fixes.Why leave it up to chance that your query will block?  Just specify WITH (NOLOCK).  13 characters that wipe clean any thought of being blocked or blocking.Of course this is bad practice, and could lead to reading data that is dirty and inconsistent, but it is easy.  Typically this is done by SQL developers that don't want to trouble themselves with troubleshooting blocking and other concurrency situations, and they'd rather take the easy way out.My specific question is why is it so overused in every organization I tend to consult with? I've seen it used for every select statement on every tables in the last 3 clients I've been at. What are the possible reasons for this?Because those that use and abuse it tend to not understand relational database management systems or concurrency models, and it errs on the side of generosity in lieu of data cleanliness.Is the memory/hardware insufficient to get transactions processed?No, that's typically not the driving factor.Is data consistency less important than it used to be?Data consistency should be a timeless goal.  99% of the time it's out of laziness or ignorance that developers use it.What is the general consensus and best practice on using NOLOCK?The best practice is don't use it unless you've absolutely proven without a doubt that you need it and it is ok.  Simple as that.