It does happen to an extent. The various efforts with Streets of Rage (Beats of Rage through things like Streets of Rage remake are also of note here) and Sonic (granted both megadrive efforts) being among the more notable in that world.
The main reason it is happening for this sort of thing though is 2d stuff prior to the GBA and DS was largely written in assembly code (a complicated way of writing code where you are basically responsible for holding the hand of the CPU throughout everything, hard to learn, hard to port, hard to debug, hard to make radical changes in your code*). PS1 and N64 then being C code which can be decompiled back into C code via a fancy program and complicated analysis of it (no comments, usually no labels, you then making labels and figuring out what the original devs intended to accomplish -- there are only so many ways to move a sprite or sensibly perform an action in coding).
It also means there is a cap -- C++ is so much more useful for coding games (see object oriented vs procedural if you want a search term to start off with there) but the additional complexity means decompilation is a far greater ask compared to plain old C. Anyway being so much better then when the systems became powerful enough to handle it (and it does have a bit of overhead compared to C or assembly, not as much as some things though) then devs jumped at the chance to use it. This means don't expect much in the way of PS2, xbox and gamecube games, and what you do get will probably be the results of source releases, leaks and the occasional bit of luck finding information in ports (the GTA on PC/Vita/Switch/... stuff largely stems from the mobile ports, Diablo from a quirk of the PS1 release and devs leave things in games all the time). PC stuff made the leap earlier so any PC stuff will probably be a generation behind that for the most part, and PC stuff mostly gave up on assembly (it lingered as it is really fast if you know what you are doing) before that -- the 89 in C89, which was the first major C standard but was around before then, being the year. Slim exception for later things using higher level runtime languages -- Java, python, lua, C#/.net to some extent... as you might be able to pick those apart.
People do also analyse the older games, however as they were written in assembly you are only going to get back assembly. Still have a look for complete/commented disassembly/disassemblies (
https://archives.glitchcity.info/wiki/List_of_Pokémon_disassembly_projects.html ,
https://gist.github.com/1wErt3r/4048722 for the original super mario on the NES
https://github.com/Entroper/FF1Disassembly https://www.romhacking.net/?page=documents&category=13 and several other things out there, including many sequels to those games mentioned).
*there is a reason
https://tcrf.net/The_Cutting_Room_Floor and similar such sites have a lot of stuff on older games when cutting a feature usually meant just ignoring that section of code and stopping it from being run as changing it meant everything after it, which could be several thousand aspects of code and data, would be in a new location and you have to go figure all that out. Today the computer handles that for you so leaks become the more dominant means of finding things, though hackers (some news sites that don't know how things work call them data miners) still find the odd thing buried in text strings or data that gets pushed before the code update, and artwork is still much the same as before as nobody can be bothered to spend a day cleaning out junk to save a few megabytes.
Source
