I'm talking about row locks.

As for row locks protecting against changes to data, yes, of course they do that.

They can also be a basis for distributed negotiation, of course. Unfortunately, SQL Server seems ill suited to such usage because there's no mechanism for it to recognize dead connections in any timely manner.

Of course that's a broader problem. In your client, lock a row, do some computation [not sending/receiving data from the database] -- then suffer a power outage or network cable cut during this computation. Now SQL Server has no idea to drop the connection or undo the lock. Now another client comes along and wants to lock the row and can't. That's a rather nasty situation even when using locks purely to prevent concurrent access to a row of data. There's a Microsoft article on loads of manual ways for an administrator to track down and resolve such an issue, but that's bunk -- the situation should automatically be recognized by periodically checking the connections.