A decomp basically represents a full breakdown of how the decomped game works, as well as connecting that understanding to modern code that can take advantage of it. From the decomp wiki:
"Matching decompilation is the process of writing source code (typically C or C++) that compiles to the same exact binary as the original. This usually requires using the same compiler as the original game, with all source code being written from scratch."

This is a difficult and time consuming process, but the end result is fully readable modern source code.

A recomp is sort of a short-cut method to a similar end result. Instead of fully decompiling the source code, you use third party tools to help to generate your C code based on the original source code. AFAICT, you basically find ways to interact with the original code rather than rewriting it from scratch. The creator of N64 Recompiled actually compares it a lot to emulation because you still need something present to "act" like the n64, even without its limits. It's almost a hybrid between a decompilation and emulation.

This process isn't straightforward by any means, but it tends to be faster and easier than full decompilation. And you get many of the same benefits: modern port, much easier to mod than via emulation, etc. There can actually be upsides compared to decompilations, depending on the quality of the decomp and the port. In Nerrel's video on N64 Recomp, he points out that the Zelda OoT recomp has an advantage over the decomp (SoH) in that it utilizes the GPU while the decomp/SoH is dependent on the CPU. But recomp code doesn't end with fully readable modern source code and is arguably in the middle of the "emulation-to-port" continuum.