There are many answers and things to ponder, though above it all "thing which gives you the desire/determination to continue" will probably be looming -- not many people are about learning for the sake of learning, and while I might say I am then I would still not have got far if all I had to look forward to was a sports game at the end of it.
Barring the really old stuff then I would not say any mainstream 8 bit or newer system is really all that much easier or harder than any other. If you can find a decent debugger for it then even better (for a rule of thumb then Nintendo systems usually have the best ones outside PC, though PS1 is not bad and Sega stuff is far from absent. Arcade stuff can be harder, as might older and more obscure systems. Sometimes you will have to go looking at the tool assisted speedrun crowd to find a debugger, or a better one than mainline emulators will afford you). A system that uses a filesystem (floppy discs, things on CD/DVD, Nintendo DS commercial games and beyond) can make life easier by virtue of having file/directory/extension/file size to look at and eliminate with (to say nothing of making certain pointer issues all but absent), and it can also complicate basic tracing that things with the ROM visible in memory ( https://www.romhacking.net/documents/361/
) have an easier time with.
We can loosely categorise types of hacks into difficulty ranges but there are all sorts of other things which can modify this, to say nothing of one particular game maybe just being really difficult in this one regard. Said categories common around here are probably
game logic (sometimes bundled with level stuff)
multimedia (sound and video)
People looking at translation* will usually immediately find themselves thrown into text stuff. Others might wander in and find graphics are their intro to it all (and translation can, usually does, involve some amount of graphical work as well). Both have many many examples of quite easy things when all is said and done, but at the same time there are nightmare ROMs that even veterans have to plan a means to contend with.
Music is traditionally seen as hard, mainly because it is, but get into systems with simple CD audio, or known formats common to 90%+ of games (the GBA sappy format for example) or even near universal (the DS SDAT format) and you can be composing whatever you like in very short order (and possibly even just sticking in wave files in the case of the DS).
We don't tend to see videos much in the sorts of systems popular around here, and even then all most would want to do is replace with another region (so much copy and paste, maybe with a minute to tweak pointers) or subtitle them (either done as soft subs or by finding an existing encoder, rarely by making their own encoder).
*the other categorisation is probably translation, game improvement (bug fixing, text tweaks, difficulty changing, censorship related stuff), game modification (new levels, new enemies, new items, unlock everything from the start....), total conversion (basically a game engine is reused to tell a whole different game, not common as it is hard and likely easier to just code your own new game). There are overlaps between them all but you can discover the literal, liberal, pizza cats debate on your own time.
Another way people look at things is everything eventually ends in assembly language fiddling, and those that can do the assembly language dance often have an easier time of things elsewhere; no need to open a ROM in a tile editor and press page down a lot if you can follow it back to the source by watching what the machine does to land it in VRAM before going backwards from there.
Assembly language is unique to a given console, especially if you consider its unique arrangement beyond the CPU (the Master system uses a Z80, as does the sound for the megadrive, and it is not so far to the GB/GBC's quasi Z80 CPU either, but all use different memory layouts, approaches to graphics, have different hardware available to them...). At the same time though learn 2 assembly languages and your third is not likely going to be too difficult, especially if you got a bit of an idea into general computer architecture throughout it all. To say nothing of the same core concepts getting you pretty far wherever you go -- instructions tending to be split into CPU/memory management type instructions (shuffling things between registers, grabbing things from or stuffing it in memory, push and pop...), basic arithmetic (many will not have divide, much less divide with a remainder, some will not even have arbitrary subtract) and electronics operations (shifts, rotates, ceiling, floor, boolean stuff...), and comparative operations to decide if conditions have been met and tell things to jump around accordingly aka program flow.
Go another way. Without assembly then whether you make much headway with a given ROM is up in the air -- most ROMS are fairly amenable to most things, however there are bad ones. With assembly then you can reasonably rock up to any ROM on a system you know (and many you don't) and be assured you will make headway in fairly short order, said headway might only be learning exactly how annoying it is going to be (there have been Japanese games with all vertical text, and said text is all graphics, or things which change encoding every screen) but you will know.
Most don't find themselves reverse engineering level formats right away, but they could easily enough -- levels are usually quite simple as it is painted or coordinate system based affairs. Whether they get right away into making a graphical level editor will likely depend upon general programming skill. 3d levels can be a bit different here (some will do collisions based on the models, most though will have a separate file/section to handle what interacts with what -- for a fairly nice intro to such things maybe look up the 3d mario karts as they have some good stuff here).
Game logic is often assembly in the end but cheats are a part of this.
For example one time someone asked for a one hit kill mod for Sonic. A hack that dealt with hit detection was eventually made but before that I just made a cheat that held the number of rings at zero (the same 5 minute search procedure ( https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial
) that gives you infinite lives, time, points, ammo... can also be used to find ring count, and set the value at 0) and turned the game into that. For some cheats are not as satisfying as being able to have a custom tweaked ROM (by the way you can hardcode cheats on a lot of systems from about the N64 on upwards, and the methods such tools use also work pretty well and are pretty easy as these things for older systems if you go manual) but in terms of end results they can have some profound effects. If you have some self control then start with 10 lives rather than 3 type things also easy to make from infinite lives cheats most of the time.
Other times if RPG balance is your thing then the game might have a nice stats table for players or enemies that the devs maybe did not fine tune. Find where this is and what it says (maybe someone came before you and figured it out) and it is so much spreadsheet editing from then on.
Choice link at this point for cheats https://doc.kodewerx.org/
. Cheats are more than infinite or setting a value that would be infinite in an easy mode style cheat so I also find getting people to ponder moon jump cheats is also good -- is there a gravity stat, can you stick a silly number in a jump stat, if the game has double jump/air jump can you find the "has done second jump" flag and set it to not jumped?
Where text and graphics can be counted on to be fairly sedate and only have compression, variable tables and the occasional dev making life difficult then game logic is as varied as the games themselves -- you say you are a dev already so I usually go with "what would I do to solve this problem"/"what could have been done to solve this problem". Game devs are not always great coders, nor overly concerned with adaptability, so keep that in mind during all this.
Start going beyond things that are basic stats, able to be handled by simple cheats to nerf or boost certain mechanics, like fiddling with fundamental aspects of 2d cameras ( https://docs.google.com/document/d/1iNSQIyNpVGHeak6isbP6AHdHD50gs8MNXF1GCf08efg/pub?embedded=true
for nice links) and you are not getting out of there without assembly.
Suppose I had better plug my own docs http://www.romhacking.net/forum/index.php?topic=14708
as they are largely aimed at getting new hackers, or new hackers to the GBA and DS. While they are aimed primarily at the GBA/DS (pretty much all the examples are built around them) but again it tends not to be all that different between systems.