The article brings up some good points, but there are several misconception. You can't compare normal user program execution with operating system kernel code execution. Total different beasts. There are reasons, that most operating system kernels are written in C and assembly. And also there is a reason why kernel code seldom use any FPU or SIMD instructions beside saving and restoring the FPU and SIMD context on context switch for user threads. ( The size of the SIMD registers in byte x86_64 SSE (256) x86_64 AVX (512) x86_64 AVX-512 (2048))

Ex. You don't want your interrupt server code use any FPU/SIMD instructions, as you don't want to save and restore the register file for the FPU/SIMD registers for the kernel code. It's just takes to much time. And there are other architectural execution penalty on some CPUs when using large SIMD instruction codes.

We measured simple operating system functions, like page clear with SIMD, and it's just does not worth it even if we only use SIMD instructions in that function and save/restore only the necessary SIMD registers.

Also heavy inter operation between low level assembly and higher level system code ( C ) are essential in kernel. You have to be able to handle the same structures in assembly and C without any misalignment and misaddressing. ( we use special macros to write down kernel structures, that are used in both assembly and C, all of the assembly files are C preprocessed)

And there are other several issues with OS kernel codes (handling special registers, changing address spaces (virtual), invalidating/flushing caches (specially on ARM), managing any kind of exception (hard and soft, page fault, invalid instructions etc. ), real-time handling, kernel context handling if any, etc.).