Well, it's does not does any thing. What is purpose of this?

Alignment of code.
CPU manual suggests that labels should be aligned by 16 byte address (for speed).
So, NOP is inserted BEFORE labels to align them.

Originally the NOP instruction was used for delays to synchronise with external hardware. Its use for that purpose is no longer possible because of the design of modern CPUs does not couple the execution with external bus activity.

If you look closely at the encoding patterns on X86 instruction you will see that NOP was originally "xchg ax,ax".

Well, did you mean this command for synchronize the communication between software and hardware? If modern CPU architectures does not supports this command, how they implement it in X86, X86_64 or ARM assembly?

Synchronising with hardware by using NOP was a common technique. But it was finicky and required exact hardware configurations to work correctly. But now such things can be handled by the hardware itself and proper use of interrupts. Things have changed a lot since those first CPUs of old.

While it doesn't do anything explicitly, the implicit side-effects are very useful:

NOP generally has the smallest possible encoding allowing for things such as label alignment without having to re-adjust code/encodings but it also allows self-modifying/dynamically-modified code for runtime patching of libraries, debug breakpoints, placeholder substitution/insertion or instruction elimination for size optimisation. (For x86, as well as the original 1 byte encoding there are larger encodings that allow faster progression compared to multiple NOPs) For more mischievous users, this forms the basis of many work-arounds

In optimised sequences, it can act as an explicit placeholder or denote pipeline delay in fixed delay pipeline architectures; this side-effect can also be used to flush the pipeline* without a potentially longer reset. Related to this, is the fact that a "small" amount of time is passed by executing it without external dependencies such as clock interrupts or bus access, which is generally useful for synchronisation - particularly real-time scenarios. (In some architectures instruction fetches can force bus fencing/synchronisation) For x86 this has become less useful due to calculations moving away from ALU to FPU/coprocessor and the implementation performing out-of-order (OoO) and shared execution.

In other architectures the NOP encoding may be aligned with the RAM default state (e.g. zeros) to prevent unwanted behaviour (except maybe starting a fire ) when starting the processor with no loaded code; on x86 it's usually a memory access violation, eventually.

From a hardware implementation perspective it's also useful for bring-up without having to worry about implementing the full ISA on top of the major interfaces and can be used to identify issues in silicon.

*Other architectures have pipelines that cannot be flushed and so require NOP after branch instructions to prevent unwanted execution [unless this is constant and so becomes an optimisation]

IMHO interrupts have always been a bad idea ... they notoriously caused trouble in the 70'ties when hardware was simple and dumb (but interrupt systems were already complicated and messy and buggy) ... and nowadays hardware is complicated and smart (and buggy) ... neverthless interrupt systems still do exist and still do cause trouble (and they are more bloated and messy than ever before).

PS: instruction NOPE is especially useful for cracking and patching