So, I’m making a game that will involve not only different screens, but different “regions”. Think of a game like Paper Mario, or Zelda 2, or maybe even Super Mario World. Say, you’re in a foresty region. You go to the edge of the screen, then you pop up on another screen, but it’s still foresty. Then you leave that region and go to a desert region. It’ll be deserty. And etc.
I coded a thing yesterday that not only has working screens, but also these working “regions”. A feature I added is that, every time you exit a region, it deletes all the textures the last region added, and re-loads new ones. But this presents me with an issue: potential for load times.
I’m not sure how many/how big the textures will end up being. Plus I’m going to be loading song loops and etc. Possibly several song loops per region. Do you think that this could end up taking tangible time to load? At this point I’m not even sure how complex the textures could be. It could just be programmer art, and characters with 4-frame animations and 16x32 frames, but once you start stacking things up, could load times start hindering your gameplay experience? Is this not a smart way to handle things?
I could just load everything up front. Is that just a better idea?
I am in a similar situation.
My game is a time-travelling 2D platformer : the player starts in 2015 for example, and after going across the level he travels to say 2500.
My problem is similar because when the player travels, new enemies come in as well as every other object in the game. This would require me to load the new enemies at runtime if I don’t load everything at the beginning, and as I am in an early development stage, answers to @HylianDev’s question are welcome for me as well 
From my experience I can tell that loading everything before the game starts is far better than loading things during the game. When loading content during the game and then disposing it creates a large memory usage when handled not properly. So the best way is to load all region textures once and then use them when needed.
My way is a little more complicated. I have a GlobalGameManager, that has my asset manager that is linked through the whole game so I can access array of imges, data files etc. Basically My globalGameManager is a drawable game component. I dont use the draw feature but required. Since GameComponent doesnt have an overload of “LoadContent”, I use DrawableGameComponent instead.
From there, I load my assetmeanager and it loads the assets.
Then access that drawable game component (the globalgamemanager) from the monogame/xna component manager system.
If you can load all assets at the start, then go for that. It is much easier and will avoid the many issues that can arise from trying to load assets on the fly during the game. If you want no delay when doing the level change, then you must have the assets loaded before the change. If all assets are loaded at the start, this is not an issue. If you have too many assets to fit in memory at once, then you will need to load the assets for the next level while playing through the current level. You can try to load assets in the background on another thread, which I have done before, but then you get into multithreaded programming and you need to know what you are doing in order to avoid getting into a mess.
I have developed games before that used continuous loading of assets in the background as the player progressed towards the next level to allow for a seamless transition. This wasn’t using XNA or MonoGame, but on PS2, Xbox and GameCube. It was a massive effort to get that system working to a sufficient degree that it wouldn’t intrude on the gameplay, and we have tried to avoid it ever since.