I always thought that was a weird move when, for example, the team who did the God of War HD remasters were asked how they got the assets they openly say they were able to take a retail copy of the games and reverse engineer them, so I wonder why that isn't always possible, but I'm also not a programmer.
It's complicated. Basically every program's architecture is, in a way, its own language, and some are more easily reverse-engineerable than others. In cases where it seems like cracking something open and getting at the gooey assets on the inside is a 5-minute process, it's more than likely because someone or a group of someones in the past spent months of their life building a tool to do just that.
The thing about programming is that its implicit reusability means that you can see a lot of the time costs in it as sort of... temporally-flexible. If a tool needs made to decompile this particular engine, it's gonna take X amount of months of work, but whether that work is done now or was done five years ago, that amount of work needs to be done at some point.
You're generally gonna be more lucky with it when it comes to engines that are widely-used - Unity, Unreal, GMS etc are used by lots of people and so it's more likely someone's done the legwork of making those toolsets for them, but especially back when KH was made (all the way up to the mid/late 00s, I'd say), the thing to do was to make your own architecture in house (Square did this a lot and it's why they tended to get so much out of their hardware), which makes it disproportionately more likely that auxiliary tools like decompilers, etc don't exist yet, as they hadn't yet been made for that particular program/engine.
There's also the fact that such tools are much easier to make when working from source code, or even just architectural documentation - if the team who did the GoW remasters seemed to get the assets from a retail copy with minimal work, it's entirely possible that, say, a tool was made during the original game's development (or they had enough documentation to know the spec they were working with) that building a decompiler took very little effort. However, if you have less knowledge, no source access, etc, it's more likely that you need to break open the executable with some reverse-engineering software, look at a bunch of ugly Assembler code, and do a bunch of upfront work just trying to understand how the thing is built, sort of "learning the language" of the program before you can start actually meaningfully interacting with it.
Basically, there's a lot of unknowns, and every programming situation is so different in its structure and foundation that you can only really directly compare things when they come from nearly-identical circumstances. You can see it as somewhat similar to learning a language - the more you know about it, the less work it's going to take, but if it's your culture's first exposure to anything in its linguistic family and nobody has ever seen it before, before you can even begin to reckon with what it's saying, you have to do the legwork of learning its structure, how it operates, etc, which is a lot of meticulous comparison, pattern-finding, trial and error, poking it with a stick, etc.
