Doing this as a matter of course for all cases when a variable is being set to null seems silly as I am certain it has absolutely no purpose 99.9% of the time. After the code has executed, the state of the variable will be identical in both scenarios. There may be a sub-sub-nanosecond difference if you need to run this a billion times, since CPU reads are faster than writes (without any caching, branch prediction, or operation re-ordering at all, writes are twice as slow, but that doesn't mean they will end up twice as slow once you add all those mechanisms back in, also the increased size of the code base and working set may offset any gains). But there is no functional difference.
It is conceivable there could be some functional difference in rare, exception cases, e.g. if the variable is marked volatile. In this case, the null check will put up a read memory barrier and will skip setting up a write memory barrier if it is already null. I can't imagine any legitimate purpose but it is possible some brainiac figured out a very subtle difference in some low level behavior, e.g. the null check may prevent a redundant null set from interfering with the CPU's write queue, solving some obscure problem I've never heard of.
I am sort of spitballing here, but I thought you might be interested in this very narrow possibility. I sure as heck never check for null before setting it, nor does anyone I know, nor does any example in any Knowledge Base article I've ever read.
Another interesting reason that a commenter noted is that it may be helpful to be able to set a breakpoint that will only fire when the reference is released. If you follow the pattern and put a breakpoint on the assignment, it'll work that way.
My final thought is maybe it is a holdover from the days when we did reference counting when releasing objects. With GC of course all those patterns are out of date now.
Perhaps don't approach this as a debate but a learning opportunity. Ask them why they do it. I am really curious what they will say.