Probably for historical reasons. I see lots of places where it is still used in the belief that it is the correct solution.
There are two issues. The first is dirty data reads; your app reads some data which is then rolled back. In practice this pretty much never happens (well, not in the APPs I've ever been involved in!) so Developers consider it a non-issue, and that's probably fair enough.
The second, much more serious issue, is when your APP is pulling some data from the server. Lets say that it is traversing an index and is about to read Index Page 1234 and just before then another user has inserted a new row into that index page. However, the index page is already full, so SQL has to split that index page.
If you are using NOLOCK one of two things can happen:
The index page is split, your query reads the first "half page" but your query is running faster than the index page splitter function, so you read the next index page before the newly split half has been written back to the disk. So now you are missing some rows (i.e. rows that were present in the table a few moments ago, and will be back in the table in a few moments time)
You read the index page and then the other process splits the page. In this example your process is running slower, and the other process splits the page and writes the "second half" to a new index page, and THEN your process reads that page. You get that second half-page of index entries a second time.
There is also a third outcome where SQL determines that there is a conflict between the two processes and terminates your process. To my mind this is the best outcome because the user will not see some-missing or some-duplicated data ... but ... that depends on what your APP does when this error is triggered - its a very unusual edge-condition, so your APP might proceed and do something goofy, rather than just aborting. If the user reports an error you'll never be able to reproduce it ...
You'll also never be able to reproduce errors 1 & 2 easily, as the timing is critical to cause it to happen, but the fact that I get email alerts of Error #3 about once a week (there are 20 people in the office, its not a big organisation ...) suggests to me that my users are seeing Outcome #1 & #2 on a fairly frequent basis