to reiterate: you can avoid resetting the machine, and for all the x million systems in data centers around the world, we do avoid resetting the machine.
But that comes with its own set of issues, including kernel version x not being able to boot kernel version y (very common with linux, no problem on plan 9); and hardware not behaving well, since few people write drivers that properly reset hardware; or the hardware can't be cleaned up absent a reset (most common problem areas are NICs and graphics). Very few linux drivers can properly shut down hardware for a kexec. The IOMMU and MSIx added a whole new world of fun. Sometimes it feels like it works by accident.
Also recall that side channels across a kexec are an issue that has to be considered. At Google we've considered them by, e.g., turning on "zero on free" and "zero on alloc" in the kernel that will kexec, only using a small amount of memory in the first kernel (32GiB is small! Ha!), among other things. But since DRAM SPD and Voltage regulator module FLASH provide places to hide things, it's getting messy.
So it's not as simple as "reset bad, not reset good". Hardware is poorly designed, or the drivers are poorly written, and absent a reset, the kexec'ed kernel may fail to boot -- lockup is common, panic is common. That said, no system I know of implements kexec with a reset in the middle.
Short history: in the Linux world, kernel boots kernel was done, in 1999, by LOBOS (me) and Eric Hendriks (Two Kernel Monte), and Alpha Power (DBLX). Werner Almesberger did his own thing ca. 2000 called (iirc) bootimg. Eric Biederman looked at LOBOS, did not like it, and wrote kexec, I believe around 2001. Plan 9 got kernel boots kernel around that time. As usual, the Plan 9 implementation was the most compact and cleanest. This paper
https://ieeexplore.ieee.org/document/1392643 compares them.
The AlphaPower DBLX code was lost when the company went under. They made a heroic effort to get it to sourceforge but things happened too fast. DBLX means "direct boot linux" -- the acronym reads better.
The first kexec was a very general interface, with a Himalayan learning curve. At some point an Intel engineer found kexec confusing and wrote an entirely new type of kexec, with a different API, that many people found easier.
so kexec has been around for 20 years, and we're still getting the hang of it, and there are still people who claim that it will never fully work.
Anyway, we're far afield of the original question, but it was very interesting to read how far back the idea goes! PDP-7, who knew?
p.s. as to an unrelated discussion: kernels have been self modifying code since at least module loaders became a thing -- that's almost 40 years. Today, especially for risc-v, Linux is aggressively self-modifying; there's no option for some risc-v SoC if you want them to work correctly. Linux rewrites the entire kernel text in early boot stages. You can consider the last stage linker optimization occurs in Linux early boot code.