For question 1, it depends.
By “Map,” do you mean “actual terrain tiles” or do you mean “position/actions of entities?" Also, what is your gameplay? An RTS with hidden information is more susceptible to cheating by sniffing information than, say, a bullet hell shooter, or a JRPG. A FPS might also be open to cheating, if there's significant cover/hiding/ambush gameplay elements. Is cheating even a concern? Co-op games generally don't mind if players cheat, because it's just about having a good time, and “cheats” are more like “mods” in that situation.
Also, are maps randomly generated? Does knowing the layout of the map ahead matter to gameplay decisions? For example, in an RPG, how hard you consume health may vary depending on whether you know whether there's a potions store up ahead or not.
In a “typical” game, the “Map” is pre-determined and downloaded ahead of time, and doesn't change between game sessions, so players learn the map anyway. Then there are entities (like, say, chests that can be looted, or health packs that are taken/consumed) and players. Sometimes, it's better to cull those on the server, either to avoid too much bandwidth/CPU usage (when the game is quite massive) or to avoid cheating. Other times, it's better to just send everything, because it's easier, or it leads to fewer bugs, or it leads to less lag in displaying newly-relevant entities, or it is required by the simulation model if you use deterministic lockstep simulation.
For question 2, I don't quite understand the question. What does “server sends information about entities” have to do with “draw players?” Are you somehow keeping the player's visible scene graph up to date on the server? That's not, generally, how most networked games work, because the latency between something happening, and the player seeing the update on their screen, will be too much, and when the scene graph mutates, there will be too much network traffic. Instead, the network protocol typically deals with a “small” representation of the player, mainly having to do with physics/simulation state, and all the “rendering” bits are determined by the client, based on what it knows about the world.
For question 3, you will typically have most of your entities in more than one data structure. The entities may be in a quad tree, to quickly find out which entities are close. Some entities may be in a list of “awake objects" that get a simulation tick every frame, whereas other entities may be sleeping and you don't call tick on them to save some CPU. Some entities may be in various other lists, for physics, or visual effects, or pathfinding, or active targets, or whatnot. Having a list or dictionary of “all monsters” may be necessary for you, depending on your specific needs.
In general, yes, every object will need a unique ID – that's how you can tell other networked nodes about updates to the objects.
When it comes to “monsters,” assuming you're making something RPG-like, they are typically either pre-placed on the map as any other entity (in level-based RPGs) or you instead place a “spawner” object on the map (which is invisible to players,) and the “spawner” has the job of making a new monster instance after its previously spawned monster has died, after some respawn delay (in MMO-style RPGs.)
