Now onto the restrictions. (This is my own speculation, but having programmed in assembler for many years and work on system level code at work, I think I can provide some insight).
PREFETCHW - This allows the application to request blocks of RAM to be filled into the L1/L2/L3 caches, as it's essentially letting the CPU know what you want to work on in the future. (eg you're about to start decoding a video stream, so you tell the processor, please prefetch this 1MB of RAM into the cache as I'm about to start working on it). This helps mitigate cache misses on memory access. (and since access to cache is a *lot* faster than main memory, this can reduce CPU pipeline wait states for getting access to main memory).
LAHF/SAHF - This allows applications (notably the kernel) to store and reload the CPU flags register on a context switch. (a context switch is when the code goes between user mode and kernel mode, and/or when another process/thread is given CPU time. This will typically occur between 1,000 and 100,000 times per second depending the kernel architecture). This allows the kernel to use 1 CPU instruction to perform saving and restoring of the CPU flags on a switch instead of, IIRC it's about 10 instructions on the 386...
CMPXCHG16b - This is the atomic CoMPare and eXchange 16 Bytes CPU instruction that allows to easier handles of mutexes and semaphores in multiprocessing code. It's also typically used with lock-free and wait-free algorithms in multi-threaded code... (remember the kernel itself is one very complex mutli-threaded application). This allows for less code to be used with those algorithms.
IMO, none of these are critical for an OS? But it certainly would make the kernel faster in a number of respects, mainly on the use of lock-free algorithms/data structures and in the area of context switches...