I've only worked disassembly of any kind with two games, NES Monopoly and FDS Backgammon. Both times were to understand the RNG and how the game uses it. It wasn't particularly difficult (making 40-minute-long TASes generally takes up a lot more time) but it wasn't easy either.
I would only ever consider disassembly for RNG purposes. This is mostly because RNGs are one of the least intuitive things during normal TASing, and are highly procedural in code. Tricks and glitches, on the other hand, are the opposite: highly intuitive during normal TASing, effectively non-procedural in code. Computers don't understand tricks, glitches, or intuition. They just do what they are told to do. Looking at code is much the same way.
Even for RNGs, it is sometimes possible to determine behavior just from trial and observation of its memory address, in which case disassembly is not needed. In Pokemon Sapphire, for which I have created a
page on RNG mechanics, I only used existing knowledge (fortunately there is a lot), RNG observation, and pattern-finding to obtain the results. They may not be perfect information (only full RNG disassembly can do that) but they are good enough for my purposes.
Another example is the infamous cannon launch event in Mega Man X5, which at the time, no one knew when the launch without parts would succeed or fail, or even its exact probability (rumors of about 1/100 were frequent). It seemed like something that would require disassembly, but through testing in a more ideal setting (a couple parts rather than no parts, which raises the probability), I noticed that on a couple instances of success, one byte of the RNG memory address, normally some number from 0-255, was 6 and 7 at the time of decision.
I cracked the code a few hours later.
As an aside, the reason for the 1/100 rumors (the actual probability is 1/16) is because players on the PSX version would keep resetting for the event, but it always used the same RNG value.
