The primary hardware reference for most people would be the pandocshttp://bgb.bircd.org/pandocs.htm
(other versions exist but are mostly the same as that).
I am not sure what the kids are using for a debugger these days (I always liked BGB debugger but there might be better options).
After that it is mostly the same as everything else -- tile editors, relative search, some very light compression possibly, sound formats can be custom but are not always, general approaches to level formats.
As mentioned pointers are a thing you will want to know as the languages you have already don't have or don't place any real emphasis on the concept (compared to C family stuff). Short version is they do much as they say and point the way to parts of the ROM (or section) or memory where things are located, if you change where something is located (or make it bigger or smaller, or want to and thus need to move to increase size available) then you need to change the pointer to reflect this.
There is nothing amazingly special about the GB/GBC that no other console saw or would see for years afterwards. Nothing that makes the GB/GBC harder or easier than anything else really. If you already know Java and Python then both of those do well at editing binary files (most ROM hackers are not fond of the java interpreter so maybe consider python if you want to share the end results).
Hex editors, as we often have to tell new hackers, are very blunt and stupid tools. While they are useful for a lot of things you don't really want to be spending too much time with one, and if you are then you have probably gone wrong somewhere. Small edits, copy pasting known data and quick observations are what they are, for want of a better term, ideally used for. I am not entirely sure where people get the impression they are some mystical and arcane skill that needs to be mastered to call yourself a ROM hacker.