Decompilation means that they can deterministically recompile the code and get the original ROM back minus assets. Someone may be able to wedge in shims of emulator code for the subsystems that need it. But at that point you're still emulating realistically and still dealing with bottlenecks. The true power of a native Port would open it up to Modern graphics apis larger faster system bus etc that wasn't available initially. It's going to take a bit more programming work before you see something that really blows the doors off emulation. But it will happen.

It certainly makes it easier but I don't know if I'd say it's easy. There's still work to be done to make it run natively on PC with the kinds of settings you'd expect to see on a PC game.

In some ways yes.

Decompiling a game means reverse engineering the game to a point that you have a program written in C that compiles to identical machine code as the commercial release. That makes it easier, but not entirely straightforward, to just compile the game for another architecture, because it might be written for hardware-specific features that might not be present on, say, PC.

A minor example is Mario Kart 64 has these big screens around some tracks that are playing footage of the race. That relies on a hardware quirk peculiar to the N64 and it's been difficult if not impossible to get it working anywhere but real hardware.

A really weird one is Super Mario 64. The retail version of the game was apparently compiled with debug flags on. The game has been decompiled, and then compiling it without the debug flag actually causes the game to run smoother, particularly in Dire Dire Docks which chugs so bad on a retail cartridge that speed runners use camera strategies to keep the submarine out of view for better performance.

Having the source code makes it trivial to do whatever you want with the code. Working through an emulator is not fun from a coding perspective.