What happened was that your mirc was somehow either damaged or wiped to size zero, so when mirc started and doesn't find a valid mirc.ini, it created another one from scratch. When it creates another one, only bare minimal settings are created, and mirc does the default behavior in the absence of that setting. The re-created mirc.ini is not completely the same as the one created during install, and one difference is that the default favorites listing isn't re-created. Since the default setting is to not have any scripts loaded except for a pointer to filename scripts.ini, your vanished scripts may still be there, and just not loaded, and assuming your global variables are still there because they were saved in the default vars.ini filename, you can use the /reload command to load your scripts into memory without running the event that triggers during an install. To see if you can salvage something, here are a couple of commands you can try pasting into your status window:
//noop $findfile($mircdir,mirc.ini,0,99,echo -a $1-)
//noop $findfile(c:\,mirc.ini,0,99,echo -a $1-)
These hunt for the filename mirc.ini and show the complete path for any it finds. The first one looks only in the mirc folder and below and is very quick. The 2nd one looks on the entire c: drive and can freeze mirc for a very long time. From what I understand, mirc itself only creates backups during install of an upgrade, so if you never upgrade, you never backup, and your last backup will be the last time you upgraded.
When you restore mirc.ini from a backup, you want to do it while mirc.exe isn't running.
While this problem most often affects mirc.ini, it can affect any other settings file that is being written to disk at the moment windows crashes, or if something bad happens while mirc is quitting. Bacause of that, the 2nd most likely file it could happen to is writing to the vars.ini containing your global variables. I even once had it happen to a script file that i was editing but was not in the process of saving. After windows crashed, I went to edit the script and found it had size zero.
To make sure it doesn't happen again, you can try using the code I posted in that other thread. It creates a timer that makes a backup copy of mirc once per hour, but waits 1 hour to do that, to make sure you have a chance to notice a problem before you've written on top of your backup. The alias posted in that other thread makes a backup name containing the name of the day of the week, so you could end up with up to 7 backups from which to choose. It saves only the mirc.ini and the variables file because those are the ones most often written to, so are more likely to have this happen.
I also made a more robust backup script that can save more of the settings files as backups. https://mircscripts.net/pVcK1
My backups should usually work because when mirc.ini gets replaced by defaults, the default is to have no remote scripts at all except for a pointer to the default filename scripts.ini, so as long as you don't save the script in the other thread to that filename, then the default settings won't be written to the backup file.
I really think mIRC should have at least some kind of simple backup system. Even if it's not perfect, it would at least offer something for mIRC to fall back to most of the time when mirc.ini gets trashed by the OS crashing during a disk write. Instead of having all the settings wiped back to default, it would at least have a good chance that it can fall back to something fairly recent. Even something as simple as keeping 2 backup files that it writes to at intervals of 6 hours, always writing to whichever is the older file. If the backup filenames turn out to somehow both be trashed too, then fall back to the current way of setting the defaults.