That's to be expected though: That's just the actual game code itself being executed! The code is not copied from the cartridge into RAM (that would just be a gigantic waste of RAM), the Gameboy directly executes it from the ROM in the cartridge.
So every single instruction being executed, you will see on that bus. And every instruction hopefully serves to either build up the current frame, or do game logic for later on.
Well... might be true 99% of the time, but it's not a safe assumption.
Nothing stopping a developer temporally copying code out of ROM to minimise bank switches or because they want to implement an algorithm with self-modifying code.
But that isn't actually a problem for this approach, because the CPU still puts the address on the cartridge bus even when it's accessing internal RAM, and you can still monitor which addresses it accesses to tell which way it's branching, even when executing from RAM.
On Gameboy copying some code to RAM is essentially required if you want to use sprites, because the fastest way to update the sprite attributes (so called OAM) is to use DMA. And during OAM DMA the CPU cannot access anything else than a internal 128 byte RAM, so the DMA trigger + delay loop procedure must be copied and executed there.
Likely true. You still do see every instruction executing on the bus if I’m not mistaken, and the overwhelming majority will still execute directly from the cartridge ROM I assume. (Happy to be proven wrong, but I imagine the code for addressing OAM is still a small fraction of what’s executing.)
So every single instruction being executed, you will see on that bus. And every instruction hopefully serves to either build up the current frame, or do game logic for later on.