looks like to me that..the bigger the map is the slower it loads.
Have a look at Dungeon Siege. The entire game is essentially brought to the player at once without any load times due to resource proximity streaming. Larger maps don't necessary equate to to longer load times (or even more memory usage) if the implementation is done well.
No, we cannot multithread the renderer....I'm pretty sure not anyway. But hell, new engines are barely doing that now - most pretty poorly at that.
Right. Breaking the renderer step down into multiple threads would be a poor decision anyhow since you need synchronicity among components. Trying to offset the shadow, LOD, or any CPU-dependent step would cause jerky artifacts all-around since locking threads to update them as a whole would be a performance deficit on the rendering step rather than a gain.
However, a separate thread for resource streaming, physics, network code, AI, audio processing, and a few other areas wouldn't hurt if set up properly.
I agree completely that newer games are barely tapping into multiple core potentials as much as they could be. Given that we'll be up to several hundred core CPUs in a couple years, it's high time that software developers begin to divide their applications into micro-manageable snippets/sub-processes. One of the few areas that seems to receive the most benefit from a multi-core architecture in a scalable way is that of off-line scene renderers that usually perform ray-tracing or other global illumination calculations -- which can easily be segmented/batched up into as many threads as need be without a lot of time-sensitive complications. Sadly, one large issue is the difficulty of using and building a design to serve multi-threaded programming in (most) languages versus conventional types.
Hopefully in the coming years, we'll see some additional libraries and methodologies pop up that help to standardize and simplify the process to a level where practicality in implementation will overstate design shortcomings.