If you want moon jump then the later DS Castlevania instead abused the double jump feature and rendered the check if second jump stuff useless (I can not remember the specifics offhand but I would probably look for a flag that is set and force it to no jump done at all points in time like an infinite health cheat or something).
Actual jump height changes can be a nightmare hack if you have collisions/hitboxes not tied to the animation* and can be a simple thing that you can change without so much as knowing what an opcode is after someone has found it, or even before then in some cases of external animation. If you are familiar with setting breakpoints and watching how things play out then you know most of what you might want to know already -- rather than setting it on VRAM though you have to have figure out what instead you want to look at, if the moon jump thing above is possible for this game then look at the flag that is set, it will not be the jump height but it will almost certainly lead directly back to the code responsible for the main height of the jump, if it is not the same code doing the second one), if not then you would figure out which OAM segment was handling the sprite in question and set breakpoints there. I guess you read that finding graphics with vba-sdl-h document and maybe adapted it to no$gba, either way you have effectively learned tracing and that is the backbone of most assembly work.
If megaman was there as a hidden extra (even one buried really deep and not available under any normal means) it can change how things play out. The graphics thing I mentioned... if you have ever seen a sprite sheet it will have a bunch of sprites on for each frame of the animation. It is not quite copy and paste but dangerously close.
*more common on older systems, any sensible GBA coder would have used the OAM properly. Though Konami handheld devs are not held in the highest esteem when it comes to code quality.
Disassemblers themselves are very dumb tools, much like hex editors are very dumb tools. They only appear powerful because someone that knew what they were doing guided it to produce something useful. But yeah if you want to run a disassembler on a GBA ROM it will hopefully give you two outputs for the two instruction sets the GBA has (ARM and THUMB in case you were unaware), and will also have attempted to disassemble everything that is not game code as well much like a hex editor will try to convert everything into text regardless of how useless it may be for that file.
Also as I am not inclined to make another reply you asked about everything being decompressed at once. Yes and no as to whether that is possible. If you have a list of addresses, or an address in the ROM that contains a list of addresses (see also pointers, the GBA is quite fond of them and they are easy enough to handle on it) then you could tell one of the various command line based extraction programs to go to each address and attempt decompression. A fully automated thing will only happen if someone has done a lot of work to generate the addresses manually at first, something like the Golden Sun editors from Atrius being a good example of that.