Ideally, you'd save every time a variable has been changed. Realistically, you want to have a auto save and a save-on-exit. I've seen this implemented and it does take up some CPU to do, but it's not going to lag you unless you have 100 people saving at the same time.
Saving on level-up depends on the leveling of the game, if it's slow, you want to save as much of the exp as you earn as possible so it doesn't take that much longer(so save between the levels). If it's fast, you don't want to save all the time and cause it to run the cpu up(so don't save every level). If it's a decent timed leveling, I'm not sure if you'd be able to get away with saving each level, but it could work and maybe even add a degree of old-school 'difficulty', having to re-earn where you were and what you had.

I don't think overlays are supposed to save, you might want to have variables you can check in the log in of the player to re-add the overlays. Skills, you should either have a list or vars to tell you what verbs the mob is keeping.

Autosaves should probably be between 2-5 minutes, so a minimum amount of data is lost. This shouldn't cause much of any lag outside of 100+ players saving at or around the same time(or on a really old/crappy cpu). And are a good feature to have WITH log out saving, to avoid the most data loss as possible. BUT, as already stated; is dependent on your game.

Saving for mobs outside of player's mobs is up to you, some NPCs might have things you want to save, this just really depends on your preference and the game you're working on.

    TestExp()
        set hidden = 1
        for(var/i = 1, i <= 200, i++)
            var/MaxExp = round(100 + (1.1 * ((i + 1) -1) ** 2))
            var/Test = "[MaxExp]"
            sleep(1)
            usr << output("Level [i]: [Test]", "ChatOutput")

Also if you have a world-wide auto-save loop, be sure to use for() to look for clients then refer to their mobs, not for() all mob and look for clients.

for(var/mob/Player/P in world)

//or

for(var/client/C in world)

Touche'. I apologize for being more vague than intended with my explanation of auto-saving.

OP - You understood Jittai's comment on searching for clients outside of mobs.

Autosaves shouldn't lag a server unless it's running on very small amounts of provided cpu or you're saving a LOT of variables. I've seen projects with upwards of 300 variables being saved and saving every three minutes run fine(granted a lot of the procs weren't optimized and caused lag from every which way randomly). Save procs aren't the most costly cpu-extensive thing when thinned out. As long as you're not saving every thirty seconds or saving large amounts of mobs at once, it should be fine. However, saving once every few levels on a easy-to-level game could work well, as long as it's not 10+ levels in under a minute, that save system should be fine. However, I still recommend saving when the mobs disconnect.

Also, I don't understand the need for ((i + 1) -1) as it simply adds 1 to the number, then subtracts 1 from it again.

The for() loop can be written differently, using num in num1 to num2

for(var/client/C)

Then just set a var/mob/M = C.mob for ease under that. or just a mob.Save().

While using a specific path for players like /mob/Players works in that it identifies client based mobs I prefer to avoid that as I feel like it's less, for lack of a better word, dynamic or modular?

Well, to avoid rollbacks as much as possible, you could delete the files with fdel() before saving over it. Up to you.

Rollbacks usually come from referencing things that get saved in multiple save files. As such you should get familiar with temporary vars. If you have to save something like a friends list never save/refer to their mobs, use their ckeys instead.