The idea may be to avoid shifting a 1 into the sign bit, which is undefined behavior.
The values in question are being convertd back to loff_t anyway, but that's an implementation-defined conversion rather than undefined behavior.
So that is to say, doing the shift in the corresponding unsigned type and then converting to the original signed type is better defined at the language level than just doing the shift in the signed type.
I think this is just academic, because shifting a 1 into the sign bit behaves the same way on all platforms targeted by Linux using the only compiler that you can use.
Well, or maybe not. The one problem there is new changes in GCC which assume that all sorts of things that used to work (and were thus de facto implementation-defined) are no longer happening in programs (because they are undefined behavior, so who would do that?) Thus even if the target hardware has stable two's complement behavior on a left shift that alters the sign of a value, and that has worked fine for years, an updated GCC can suddenly decide that it's okay optimize based on the idea that the program doesn't do such a thing.
On a different note, the proposed change is jarringly ugly because u64 is size specific, whereas loff_t isn't. A long long isn't defined as 64 bits; it is at least 64 bits. On a system that, say, makes long long 128 bits, the proposed code change is not correct. To make this change with the proper elegance and precision, what you need is for loff_t to have a sister unsigned type that pairs with it: a uloff_t.