For the DS that was and remains one of the main approaches used, though you might also want to look up some of the stuff Atrius did for his GBA Golden Sun editors.
Header detection, magic stamp analysis, fingerprinting of structures within it, things like 8h usually being the file size.... are all things I saw programs, did, taught and tried to note.
Unless you are wanting to go some kind of more automated pattern analysis -- if you have a 16 bit colour then most systems will tend to discard a bit to give 5 bits per colour channel, thus you are exceedingly unlikely to have F as a result in your graphics, said graphics are unlikely to be random noise so runs of stuff might also be worth a look, even with 256 colours most devs still used far fewer or at very best used some kind of shading, an emulator auto driven palette search/logging could be fun to see, the most common location for the GBA game cartridge was 08000000 through 09FFFFFF, though as things were less than 16 megs then it was 08 all the way and thus if you had a lot of 08 with 3 bytes in between then you likely have a pointer map/table/field/whatever so an automated map of the results of that, some kind of pointer analysis/limited decompilation/proto api looking for instructions that tickle certain parts of hardware and then almost immediately do something (again on the GBA a slight variation on that is used to track down the binary, possibly also parts of the sappy sound format many GBA games use), we know what valid opcodes are so some kind of statistical analysis where invalid ones are not so common, possibly the same as before but also weighted so we are not looking at the once in 10 programs type opcode is downplayed in favour of "add r1, r2", better yet you rather have a compare without a jump and so on. Much of this would probably be more signal than noise but I do see things like it in malware analysis and obfuscation is the order of the day there. I do not see it making life much easier for anybody, certainly not newcomers, and instead be more likely to give interesting threads for already versed hackers to pull on.
Before I head too far into that world an idea I have had kicking around for a while is I want to see/do some full comparative ROM set analysis. I say the DS SDAT sound format is common and ignoring region dupes the list of things that do not use it is small, with the whole thing to look at I would know for certain and some decent stats on directory names and more besides. Vendor spam on Friday had a 6TB hard drive for not an awful lot and that would probably do nicely for what I need here. I reckon some interesting things could shake out there, indeed we see a very limited version of this in MAME where you have 6 games ever made for a given board and an interconnected analysis of the lot.
There is a slight hesitation that some might read too much into things, but at the same time I am all for common knowledge that is actually wrong to be blown away by meta analysis or some kind of controlled test.
On dev kits I am not sure how useful it would be for many of the older consoles. I have not looked much at what there is for the SNES but the megadrive one on this site is not terribly useful. Most such things I see tend to be more http://www.pagetable.com/?p=28
than truly useful.
I would also be wary of looking too much into them lest we end up doing something like the original xbox homebrew scene where they used the official SDK for most homebrew and thus could only have cloaked distribution of binaries. Nothing is likely to happen but why poison the well for no great gain.