With Sean and Blue's excellent answers regarding physical platform limitations and pro-con decisions, I'm going to expand a comment into a different approach:
Why You Should Probably Just Completely Reload The Level
So you've got your loadLevel() call working perfectly, yay! You stream in a level file information, and step through building the world based on it, creating objects and loading textures and sounds as you go. Then, when it's all done - or done "enough" to let the play start, you call startPlay() and your world is revealed and your music begins to play.
Now when you are done with the level, or escape to the menu, or exit the game, you call unloadLevel() to free up all the resources and memory you've been holding onto to allow a smooth experience.
Now, what happens when you want to add a "Restart Level" feature? Well...
And you are done! No new code, just a few simple function calls at most, and you've already written and debugged all that so now your new shiny Restart Feature is crossed off your list, and probably never to be encountered again - cruftless, non-rusting code is the best kind! Move the code into a restartCurrentLevel() function and you can fold that code away and never look at it again - maybe after making sure there is a level to restart, of course :)
But then you wonder if this isn't a waste, unloading things you are just about to reload again anyway. Well, if your levels and resources are small then the most you have to gain is a few spare seconds of load time each time "Restart" is called even on slow systems (and maybe older smartphones), so who cares? "Premature optimization", you've got better things to do with your time.
Ah, but now your levels are growing and your textures are becoming more detailed and the soundtrack got ripped in 512kbps with separate channels for every voice and musical layer (it seemed like a good idea at the time, though you can't remember why...) and something about "state-origin dependent voxel ray tracing multidimensional Fourier transform matrices" which you think is just totally made up and not a real thing, and level loading actually takes a while now and its beginning to annoy you. You've even tested with real people and they actually show a distaste for the waiting times as its worse than similar games (you aren't expecting an MMORPG capital city with 100 players to fully load in <2 seconds, are you?), and it's a problem.
So how do you optimize? Well, if level re-loading is a problem, then isn't level loading a problem? If you think it's just reloading, why on earth are people reloading your level so much more often than they just load the level in the first place? Sounds like a game play problem, not a code-engineering problem. Who thinks its fun to reload a level over and over and over again, and just wishes it was faster instead of entirely avoidable?
Fix the real problem first!
But lets say your game is designed so you are supposed to restart at least occasionally, and the load time is long enough that its OK to do once and utterly unavoidable, but you don't want to have to do it again. What kind of game is this, anyway? Seems like a bit of a weird problem...maybe a high-resolution Portal-like game where its assumed you are going to mess up the puzzle repeatedly?
First of all, you have to realize that this isn't going to be trivial. You are going to have to write completely new, untested code, and it's "state-dependent" so that you might not even know what is or isn't going to be reused between level plays. Are there random elements, spawns, variable textures (do your skeletons only sometimes wear armor?), or other changing elements in your level? Are there things that vary with the player, like an outfit or customized model or colors/doors/traps?
You are going to be doing comparisons, and lots of them. You are going to be looping through level elements, comparing what will be needed versus what is loaded right now (what do you do with stuff that was loaded for the last level but not for this one - release them or hold on to prevent a future load?). If this is really a big deal for your game you are probably going to want to change your load/unload code to see if something is already loaded before loading it (making the code multipurpose but potentially introducing new bugs to previously working features, and functions that carefully release resources that aren't going to be in use in the near future). Sigh.
No matter what you do, even if your game is simple, you are going to get into obscure bugs that are based upon level/player state when a level was restarted that doesn't happen to you load the level the first time. So you get to write game updates with text like:
"Dropping a helmet on a bomb onto a tile that had a missile explode near it that was also within 200 pixels of water will no longer corrupt your game data or cause the game to crash."
The Real Reason Most Games Don't Bother
Have you ever noticed that most people just paint or drywall over their existing walls instead of stripping down to a base layer, or lay carpet right on top of hardwood floors instead of pulling them up?
The simple fact is that it's all more work for minimal reward. Painting over your existing walls works fine most of the time, and the value of ripping up hardwood floors is often minimal or nonexistent.
The same is true in software, from games to multimedia Power Point Presentations - if all you do is shave a few seconds off a loading screen people spend 1% of their time looking at, then that better be incredibly trivial to do or you are getting a very poor return on your invested time.
And so most games don't bother, and I have trouble thinking of very many games where loading screens made an otherwise good game less worthwhile, except a few extreme examples; the extreme examples are where optimizing for faster level loading makes sense, and that's a tiny fractions of games that make it to the public, and probably even a smaller fractions of games that no one ever sees because they never get released.