Like many things, it’s very fact-intensive, varying in different circumstances. As others have noted, the abilities of the person undertaking the decompilation will influence the decision. But so will strategy: the overall goal can drive how decompilation is approached.

For example, suppose you’re working for an airline company and need to rewrite some software used on an ancient IBM System/360 machine and was written in the COBOL language, for which no source code is available and you cannot find many people who even know COBOL. Here, since the task is to rewrite the code, decompilation is just to tell you how it works and then you’ll want to write the new program in a modern language. It may be useful to decompile to a different language if such a decompiler is available, say to the C language, which you better understand.

Sure, it may be that C isn’t what the new program will be written in, but if your C reading skills are sufficient, then this is a valid strategy.

The skill of a decompiling engineer – or any engineer really – is leveraging your skills and your tools to tractably attack the difficult problem at hand. Many equally-skilled engineers can plausibly approach the same problem differently.

Probably depends on how comfortable you are at reading assembly instructions for your specific CPU, but I think generally the contextless source code is probably preferable. Either way you’ve got a headache of an investigation in front of you though.

here’s an example of what it might look like with either option