Actually, defining assets in an XML file or some other easy to modify asset manifest can be helpful because then you can change the specific piece of content without changing or recompiling your code. E.g. say Cthulu monster is represented by a string and a file (so the C# code loads the manifest file, looks up cthulu, and uses whatever file path is there). If say you or a third party wanted to modify the Cthulu monster with a new skin (say, he's red and you want to make him blue hued) then its very easy. I don't know if this is the case in the sample RPG kit, but I'd imagine if they're defining assets outside of the C# code this may have been the intent.

1) You are not necessarily beholden to loading everything in a single method. LoadContent() is called once at startup, but what if you have multiple levels each with different content to load? Or what if you want to organize things, like you say, let objects load their content. So yes, passing around a content manager is perfectly fine. The idea is just to load everything once at startup, whether its program startup, or world/level startup, so you don't have to load assets during gameplay.

This also is another reason for using something like XML files - you could use an outside file to define how worlds/levels are setup and what assets to load up, etc.

You don't necessarily need to keep unloading content everytime you change levels or a monster is killed either. Since you're doing something 2D and using sprites (textures), multiple monsters of the same type only ever need to load the same texture once. It wouldn't be smart to keep having to reload the same texture, because that's simply wasting space. It would be smart to re-use assets between worlds/levels too - don't just wipe the slate clean and reload everything, when you may only have to load/unload some things, and not bother with other assets that are already loaded. You can also use multiple content managers to better organize the lifetime of your assets (e.g. a content manager that loads everything in a level, another for things that are common between each level, etc).

2) The content manager in XNA caches everything it loads, so the same content XNB file ultimately gets loaded exactly once when using the same content manager. So yes, it's all in memory, and yes usually for an XNA game (and most games) you want to load everything up front. Now that's not always the case with some very very large world games, where things may have to be loaded on demand (e.g. Minecraft, a simple looking game, actually is rather complex in its "infinite" world setup - you would not want every chunk loaded at once!). Also hardware considerations may have to be taken (e.g. developing for Windows Phone). But for a 2D sprite game, you shouldn't have much of an issue. Although it does depend on how many textures you're using, and for how long. If you have lots of textures, only have the ones you really need loaded up (goes hand in hand what I described above with multiple content managers, etc). Again this may be overkill because you could still have lots of textures, but very small ones too. You really have to look at how big your sprites are. And really, you may not have to give this a lot of worry until your performance is actually being affected. So, start working on your RPG with the default content manager provided and go from there!

3) I already answered this, but for completeness - the content manager loads an XNB asset only once, so if you load a monster sprite (texture) for the first instance, and load it again for the second instance, the content manager looks up the texture it loaded before in its cache and returns it. Now if you have two different content managers, and you load the same asset in both, you will be loading the same texture asset twice into memory. Separate content managers have no way of coordinating this, so it's up to you (all they really do is cache assets in a dictionary using the file name as the key).