I'm still not sure why. Assuming that you're using a shadow map for each light, you can render all the shadow maps before you do any lighting (this will require a separate shadow map for each light, but... how many lights with shadows do you have?).

So I'm guessing that you're re-using the same shadow map for each lighting pass, which makes sense. However you should still be able to do this, and preserve the contents of your lighting render target. You just need to create the render target with RenderTargetUsage.PreserveContents.

I am avoiding using preserve contents because I have an eye towards porting to <as yet unnamed> platforms, particularly Windows Phone 8, which I am barely familiar with (or even Windows Phone 9...ie future mobile platforms will undoubtedly have the graphic power eventually.)...DEFINITELY moving to SharpDX & MonoGame asap, and yes I have read that preserve contents is not XBox friendly....so trying to keep my options open for unknown platforms.

AFAIK, this is only a concern for Xbox360 (I don't know of any other platforms that don't preserve render-target contents when binding).
The main graphics APIs - D3D9/D3D11/OpenGL/GLES/WebGL - all do preserve RT contents when binding.

If you're interested, the reason that the 360 appears not to preserve contents is because you're not actually ever rendering into the render-target that you've created! That sounds strange, so I'll back up...
Most GPUs have a whole heap of RAM built into them, which I'll call VRAM. Everything from RT's to textures to vertex buffers live in VRAM. When you receive an input to your vertex-shader, or perform a texture fetch, it comes from VRAM. Whenever you output a pixel from a pixel-shader, it gets written to VRAM.

The 360 is slightly different: As well as VRAM, it has a separate 10MiB "EDRAM" chip. The only place the pixel-shaders can output their pixels to is this small EDRAM buffer, they cannot write directly to VRAM. After you've finished drawing everything to EDRAM, the GPU can copy it's contents back over to VRAM in one big chunk.

So the internal rendering procedure on 360 is:
1) Create a render-target/texture in VRAM.
2) Bind the render-target.
2.a) Internally, create a new temporary render-target in EDRAM.
2.b) Optionally, copy the contents from VRAM into EDRAM (preserve contents).
3) Render pixels into the temporary render-target.
4) Copy the temporary EDRAM target back over to the real VRAM one.

Whereas on most other platforms it's:
1) Create a render-target/texture in VRAM.
2) Bind the render-target.
3) Render pixels into the render-target.

Given this unconventional design, yes, an optimal rendering pipeline may be different on the 360, because switching render targets is an expensive operation (whereas on other GPUs it may be "free").

If you're targeting the 360, you should definitely take these quirks into account.
If you're targeting another platform, you should find out what quirks it has and design around them.
You cannot optimize for an as-of-yet unknown platform by optimizing for a different, unrelated, platform.

Mobile GPUs will likely operate quite differently to both the 360 and to PC GPUs, so the optimal method for them will be different again :/