You can run period of emulation time at full speed as long as difference in speed is not observable from outside. There's no point to delay regular memory reads

You can run period of emulation time at full speed as long as difference in speed is not observable from outside. There's no point to delay regular memory reads and writes by synchronizing every CPU cycle to real time: no one will notice that. If it writes to video memory, result is usually not instantly visible too, and becomes visible only when screen scan position approaches that position in memory. Probably Game Boy has some sprite hardware and changing few registers can cause huge changes on screen, but anyway it's not possible to output changes on screen instantly to host system, so you can draw whole virtual frame at full host speed, considering that you keep track of scan position based on elapsed CPU cycles (T-states or something like that). Once your emulation time period between two screen frames is completed, you can pause emulation until it catches up to next frame in real time, making process sleeping and not consuming CPU in between frames. Input events and sound add additional complexity, but it's doable.