Break on read
You know where something is in the ROM (or RAM if it started life as you making a cheat) and you tell the emulator to stop (or log) when that area is read by something.
Break on write.
You have an area of RAM you know something ends up in. You set this and the emulator will stop (or log) when this area gets written to and tell you what did it. Many times the instruction itself, preceding instructions or the other register states will tell you where is reading from as well. At first most use this for graphics (know a font lands in this place, set a break on write there, start the game/section again and watch it read it from the ROM), but it soon becomes useful for all sorts of things (if you know a stats table in RAM then you can find it in the ROM, or the save).
Break on execute
Not all the ROM or RAM (varies with system -- stuff like the GBA will mostly run code directly from the ROM section, stuff like the DS and anything that runs from a CD or floppy disc will most likely use RAM) is code for the CPU (obviously you have graphics, music, level data...). The breakpoint will stop (or log) when the CPU runs code at this location. At first most would probably use it to help with subroutines -- if a game does something fairly complex but infrequently/at essentially random points (you typically don't die in a game exactly every 5000ms or at the end of a song) it will tend to kick it to a subroutine. You can use this to help you find everything that calls this subroutine. Not a great example but when we are first teaching assembly we will often teach people to convert a cheat, say infinite lives in Mario. A cheat is easy -- you have one life counter unless it is an anti cheat game, however the assembly for it may have many things that touch the life counter (pits, poison mushrooms, time, crushing, enemies, hazards...) so you would have to find everything that removes from that to do infinite lives, assuming it does not kick it to a subroutine anyway.
Another first/early use is for stepping through code. You might know where a section of code is* and what the end result is or generally is, however the methods it uses on the way may be useful to know. Classic examples are for figuring out stuff like
https://www.dragonflycave.com/mechanics/gen-i-capturing (a "hidden" mechanic or calculation the game does) or figuring out custom compression.
*for the "hidden" calculation/mechanic you might bet on it eventually using HP or another stat. You set a break on read for that stat in RAM, go into a position where it will calculate something based on it (say a fight in a game) and now you know what is reading the stat to use.