While any game could have something which makes a project end up a nightmare there are safer fields than others. That said I still have to say "find something you want to do" -- if you are not having an end result to look forward to then chances of you finishing the project are low, and even if you are the kind of person that learns for the sake of learning or can see to the future it still does not hurt to have something you want.
From a hacker perspective translation usually blends a few areas together (mostly text and pointers handling it but also fonts so some graphics, general ideas of ROM layout and other good stuff) however unless you know the languages you will need a translator to work with and they are both quite rare and usually reluctant to work with people that don't have a proven record. A script cleanup might be an idea here -- often all the same technical fun but none of the pesky translation woes.
I would tend to suggest you go with a system that is well documented. If you are trying to piece together info from leaked dev kits, individual chip documents, emulators and similar such things then you are going to be troubled. Anything from the 8 bit era onwards (home console or handheld) that was reasonably popular* and made by Nintendo, Sega, Sony or Microsoft will be OK (though few really do much on Microsoft systems), some other home computers/minicomputers also have fairly decent followings and were often quite open at their time of release.
*while there are some people doing virtualboy homebrew and thus a means in it would not be my first port of call. Also despite http://loveconquersallgam.es/post/2350461718/fuck-the-super-game-boy-introduction
then I would similarly avoid the extra device scenes at first.
If you can emulate a machine then so much the better. If you are burning discs every time then that gets expensive, and even on things when you just have to copy to a USB drive or something it is still a bit tedious and typically lacks debug options.
Project wise I mentioned the nature of translation already.
Sound varies between systems. Stuff like the GBA onwards, and PS1 onwards, have things that are reduced to what are ultimately simple tools, ones that work for the vast majority of games, and workflows that anybody can follow. Older systems tend to have custom audio for games, and hardware to match complexity.
Level editing can be nice, and depending upon how far you want to go can start to bring in text and graphics.
Stats editing does well for those looking to start out modifying how games work rather than how they look or their text.
By similar token learning to make cheats also gives you a good grounding in how games work.
If you want to jump right in with the programming thing there are options (learn to trace maybe) to head towards having assembly hacking as a skill. There is nothing that says you have to learn to edit graphical tiles and edit text first, indeed if you have a reasonable command of assembly then the other two will be easier to pick up, and you will be able to solve problems that you might encounter.https://docs.google.com/document/d/1iNSQIyNpVGHeak6isbP6AHdHD50gs8MNXF1GCf08efg/pub?embedded=truehttps://www.dragonflycave.com/mechanics/gen-i-capturing
Not explicitly hacking but the hackers around here tend to read such documents (give or take the dislike of pokemon preventing that from happening there) or will be able to make such a thing, and might even think in such a way. Or if you prefer there is a reason why despite the original question being a very rare thing as far as examples, and several of the exceptions mainly being there because a dev locked out the option somewhere but left the code in, that people were able to say hold up. If you can get to the point where you start to figure out the requirements and outline a path then you will probably have arrived as it were.