Old sources for various ports IO stuff (like reading from/writing to kbd ports) include delays in a form of JMP $+2 after IN/OUT operations. Well, if I recall correctly, this delay is not necessary on modern systems. Cannot find detailed info on the subject on the Internet. So, my questions are:
- on what processors this delay was necessary and why?
- since what processors the delay could be omitted?
- is it related to all peripheral devices or only very slow ones?
Any information and/or links are appreciated! Thanks in advance

Your question is fairly general. I would say that there are a lot of different places where delays are need in order to allow peripherals a chance to do what is being requested. This is very specific to each peripheral though. As keyboards go, there are so many different types and so many different interfaces, to be general, it is worth studying each and understanding where they are needed for your particular application.

Speaking generally, this still is a problem for hardware today because the CPU operates much faster than the peripherals it is talking to. Most of the time this is the classic race condition of write a command and poll a status but it immediately returns "done" because the device hasn't even had time to process the request and switch to "busy" so it's still "idle". Introducing a sufficient delay was the only way to get around this problem.

Nowadays, this problem has been avoided by moving from PIO to interrupt-driven synchronisation except where real time is still important and the delay in handling an interrupt is too long.

on one very specific note: "jmp $+2" is never a valid method to delay the processor as it's not defined to produce a temporal delay.

in general a delay is needed in device/usage specific cases.

if you read from the SAME register as you wrote to then you don't need a delay as the processor doesn't re-order IO instructions. nor does the processor cache the earlier write (no write forwarding). only the IN and OUT instructions count as IO instructions. if you want MOV to behave like IN/OUT then you need complex MMU handling (Read up on MTRR, Memory Type Range Registers).

if you issue two writes to different registers then you don't typically need stalling between the two writes.

if you issue a write to the same register as an earlier write then you'll usually need a wait loop especially with older hardware.

all of that said; the majority of delays you'll encounter will be waiting for responses from hardware after issuing a command (a write) such as the standard ATA command if you use PIO.

some of the wait loops I can recall are:
ATAPI Packet Command (the ATA HDD using DMA and interrupts doesn't require a wait loop).
Floppy "Send Byte" command requires waiting for the device before sending each byte.
I think the Serial Port has the same type of delay as the floppy send byte.

there is also one other case you should be aware of but I've only seen it once in the Real Time Clock. for a small period of time (each second) the RTC goes offline preventing updates but not reads. to ensure correct usage you need a wait loop that ensures the current moment in time isn't an update cycle. if it's not an update cycle then you're free to write the registers. it's a strange case that can lead to deficient solutions (waiting for the update cycle to happen, then waiting for the update cycle to end) but it's one case that you should atleast be aware of.

- Stefan