Requirements often don't directly address transactions and locking. Non-functional requirements normally don't specify or limit T-SQL methods. A table that describes the preverbal "it depends" by relating requirements to T-SQL methods would be valuable to business analysts and developers.

An incremental approach can be valid where the process must allow existing processes to continue unaffected. Set based integration using NOLOCK should not be the first and only solution. But it might be appropriate, depending....

I currently don't often see cursors used where they are not needed. Like scalar UDFs, cursors have gotten bad name. Several years ago I attempted to follow the logic of a procedure that uses nested cursors and nested procedures. It was mind bending. I did not see the requirements, so the methods used might be appropriate. For example, the primary requirement might have been "The logic must stump and stupefy any DBA attempting analysis of the procedure."