You are using the savestate system to save the game. While you can use the savestate system and Ashley even shows an example. It really isn't the best way to do it.
Using the savestate system saves every object and every bit of data on those objects. This means all the static terrains that never changes. all the background art everything saves. This results in a save file where 99.5+% of useless data. This actually uses up a lot of save space. I suggest just printing out a few objects just to see what get's written. You will be surprised.
So of course there is a behavior to stop saving certain objects. Every tree position doesn't need to be saved. So you used the behavior to stop saving data on certain objects. And this is better approach. As this will reduce the amount of data you save. This will result in a much smaller file. But probably still 90% of information you won't need.
Keep in mind that the save system is a savestate which is meant to mimic the state of the game in memory. Including all the global values that carry over between layouts. Think of this is needing to reload a game on a mobile device when switching apps. Players except to precisly resume their game.
A save game only needs to save pertinent data that has meaning and doesn't need to reduplicate the memory state of the game. Mario, Assasins Creed, bioshock, GTA..... don't do save states. They record meaning information on progress and positional information.
So your jerk pause for 1-2 seconds is likely due to writing far more information you need. I wrote a savegame for The Blue Code and the save is unnoticeable because the data is less 300byes. In relation 1object in savestate is about 200+bytes. So you could be writing possible 100's kb of datam heck maybe even in the mb.
I suggest ideally to use proper save information for save games. And use save state for resuming games if your on mobile. It's more work though as you need to store the data and interpret the data. Where the save state is certainly far more convenient.