I would guess that PaXTeam has spotted that the i386 code is different to the x86-64 code here. The i386 code is easier to understand, because it essentially marks out boundaries such that any 32-bit access will be inside the kernel stack. On the other hand it's a bit more complicated because x86 calling conventions are a bit weird. In contrast the patched x86-64 code is less explicit, forbidding an access exactly at the edge (outside) of the stack but the convention it is implementing is more straight forward.
If the pointer was somehow not to be 64-bit aligned, then the patch for x86-64 leaves open the possibility of an unaligned pointer access overlapping the edge of the stack, which would be caught by the equivalent code from the i386 kernel. My understanding is that the x86-64 ABI forbids this in general, but perhaps PaXTeam knows better, at least in regard to the kernel stacks.