Well I like to code front ends and I don't mind saying that I've used sql successfully, I like to do the optimistic concurrency thing, with a well indexed table the lock lasts just as long as needed for a single row update, thats pretty much all I need for like a data entry or update form. After that, its just programming as usual. I get all the benefits, such as parameterized queries that don't bloat the proc cache. Theres no need for lock flags if you use optimistic concurrency, if the "rows updated" says no update has happened, you know someone else has updated the same row before you did and you code for that eventuality. No flag needed.
I can see I described your own db programming practices very well. 🙂
Can you explain why do you prefer to use NOLOCK if "the lock lasts just as long as needed for a single row update"?