I think this must have changed between 286 and 386 (though I haven't tested it on a 286). The 386 documentation says that that LOCK is IOPL-sensitive in v86 mode, though. I can't see any mechanism for this in the microcode so it must be handled by random logic, unless the documentation is wrong (which is possible - the documentation for the LOCK instruction itself doesn't mention the possibility of a #GP for IOPL<3 in V86 mode). I suppose on a 286 (or a 386 in V86 mode) the idea is that the OS is supposed to catch the #GP and simulate the effect of the locked instruction. But that is going to be very slow when ideally a "LOCK XCHG" should be fast. I suppose that is why it was changed with the 386 for protected mode applications. 8086 applications rarely used LOCK so the #GP there perhaps doesn't matter.

LOCK does actually work fine on 8086/8088, though, and does something potentially useful even on instructions where it would be disallowed on the 386, as long as those instructions do more than one bus access. On the 8086/8088, LOCK just prevents any other bus accesses between the bus accesses of an instruction (so if you're doing an "OUT DX,AX" on an 8088, you won't get a DRAM refresh cycle between the first and second bytes of the output, for example).