I work with analog electronics on a daily basis for my job, so I think I can answer some of your questions. I'm no expert, but I do have experience in the field
The circuit pulls /CE high to protect SRAM... I guess you must also have something (=address decoder) that pulls /CE low when needed?
Yep, I'm using a 139 decoder, just like boards without the MAD decoder. Verified the wiring with the manual, should be addressing the RAM correctly.
A few power cycles sounds as if it could require a bit more testing. And does the game verify SRAM checksums to ensure that all bytes are still intact, or did it just "seemed to work" despite of several potentionally corrupted bytes?
I loaded up Super Mario All-Stars and played a few levels, and saved. Turned it off, let it sit for a few hours, then put it back in and loaded the levels just fine. That was yesterday - tried again today, and still worked! It's still plausible that this won't work perfectly and something gets corrupted in the future, but I can't really see how that would happen.
Could there be some current leaking from /CE towards address decoder? For example, if the SRAM takes 1uA in standby (or so), and the address decoder leaks another 1uA then you would drain the battery twice as fast as needed. You could try to measure power consumption with/without address decoder connected - though multimeters might lack accuracy for such small currents.
So I don't see anything on the decoder datasheet that would indicate a leakage, but there might be a tiny bit. I'm pretty sure the decoder outputs are open-collector, so they act as if they're disconnected when they are not powered on (they're transistors internally). And you're right, at least my multimeter wouldn't be accurate enough to figure that out!
Diode reverse current leaking: 1N4148 datasheet says 25nA at 20V (=supposedly even less nA's at 3V), so I guess that isn't much of a problem, even when using cheap diodes. Or would it be recommended to use battery-friendly diodes in such circuits?
I'm using 1N914s. The reverse leakage is only when you're biasing the diodes backwards, i.e. when you apply a higher voltage on the cathode than the anode, so I don't think that's applicable here. The only time this applies is when the SNES is on, there might be some minor leakage into the battery, but nothing serious enough to damage it. The current we have to worry about is the standby current of the SRAM chip, which I can't really control anyway.
Looking at cart edge connectors for cartridges for different consoles, the supply pins are often a bit longer than other pins. I guess that's supposed to give clean power up/down on hotplugging, maybe specifically related to carts with SRAMs.
Some SNES carts can be ejected while powered (and power-switch get's move to OFF position, during ejection, not sure what happens first: losing cart edge contact, or losing power, but I guess there'll be some signal spikes, especially if the cart edge contacts are a bit dirty).
The professional battery controllers are also handling SNES./RESET and check if SNES.VCC drops below 3V (and disable SRAM access in such cases). Nintendo seems to have considered that required, and they've probably considered millions of users playing hundreds of games - and wanted to avoid angry customers reporting lost game positions after several months of playtime.
This is what I suspect they use the transistor for. I figure that some voltage spikes might be enough to kill the chip, but then again, they didn't really implement this on the NES and I don't see why the SNES would be more susceptible to game erasure than NES games. And if you have a big enough cap across the VCC pin on the SRAM, that should be enough to let it ride out any kind of transient voltage spikes.
If your SRAM is large enough: You could store the game position twice (with checksums) and use 2nd copy if the 1st copy got corrupted.
Theoretically, ECC error correction might also help, but that's probably too difficult (you'd more likely find that in CDROMs or dotcodes, not in SNES games).
Hahaha well that never crossed my mind, but it definitely could be done. That'd be a decent amount of work though. And I'm trying to use these in a "universal" board that can handle all SRAM sizes. But those are good ideas, definitely.
The fact that the circuit is pretty simplistic led me to ask why I didn't really see it anywhere else online. I'll update this thread if I ever run into any problems.