You can get phantom reads and repeat reads using the default iso level of READ COMMITTED. The only thing NOLOCK adds is dirty reads. And you can greatly reduce the chance of those by setting cursor threshold to a reasonable, positive value (200 or whatever); naturally you should set it back when you are done with the reads. That setting is not going to cause errors with results, it might just (in theory) cause less performance for your cursor'ed reads. And most people don't use very many cursors at all, for very good and well known reasons.
I'm not saying to use NOLOCK indiscriminately, but it should definitely not be banished. There are certain cases where it can work very well, such as just query a master table for existence of a row, or reading from a lookup table (such as a states table).
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."