It seems like we are using the higher level TAS definition rather than the more general one where TAS = anything that is not pure player skill/could be done on hardware -- you could otherwise play stock game but using savestates would make it a TAS.
I am not sure how useful this would be. Most issues in ROM hacking that I see are more memory management (though this is less an issue on the SNES and more on filesystem/unmapped cartridge/CD things, until you play with graphics anyway) or combination logic (see things like Final Fantasy and how many hack patches fix say issues with reflect) as safe coding practices and bounds checking were not exactly the norm in SNES era, to say nothing of assembly coding making such things a bit harder.
TAS grade/oriented emulators do make nice toys and if you are waiting on a proper hacking grade thing to be made then they often provide a means to get some things done.
Unit testing is great for minimal input and minimal state things (like a lot of electronics), as well as things like medical devices that have to function perfectly, but for games the paths taken are near infinite after the first second of play, you seemed to appreciate this though and already narrowed it down.
You might have something for a game like megaman where you want to fire a weapon, swap before the frame is done and fire another (testing graphics mainly, logic secondarily), you also have the "what is humanly possible?" thing to contend with.
Probably the biggest hacking type use for it would be those ripping assets via emulation that do not so much want to get their hands dirty fiddling with cheats (though TAS stuff does conditional things so much better than cheats).
That said emulators are now often seen to include general scripting options, typically using lua, for various reasons which can include this.
Crash detection probably falls under the same problem as infinite loop detection aka the halting problem.
If you wanted to do this as a learning exercise I could see you learning a lot from it.