It's the same.
Things are drawn in two main passes - one for global shadows and local interactions, the other for local shadows and global interactions, but there is no distiction made on the basis of what's casting the light or causing the shadows.
At this point in time I've got something nagging at the back of my head about light origin, view origin and the near clipping plane, but I can't quite put my finger on it.
I've noticed that too. Communications Transfer is particularly bad; try turning on the flashlight at the same time as the service lift is coming around with it's own light; that really hurts performance in the original.
I don't suspect that's down to anything special about the flashlight; just that everything in the view frustum is a candidate for both receiving light and casting shadows when the flashlight is on. The same would apply to any other directional light close to the view origin and pointing in the same direction.
My own engine works with frustum culling and sector detection to determin which objects have to be rendered and which have to be skipped for the frame.
There are some things to consider when it comes to using lights and casting shadows of objects when using frustum culling:
You can't just render shadows only for those objects that are visible.
You also have to consider objects which are close to your view frustum (above/below/right/left), not visible but cast their shadow into your viewing frustum.
If you only cast shadows of objects that are visible, you'll switch on the shadows of an object when it comes into view and switch it off when you turn away, ignoring the fact, that the shadow of the object you don't see might still be visible.
This applies to all shadows cast by objects and lights that are not fixed to your viewpoint, meaning being fixed or moving through world space on their own
if you see them or not.
This is different when your light source is always inside your view frustum, pointing along the viewspace z-axis like the original 2004 flashlight does.
A simple frustum culling detection would be sufficient to determine if the shadow for that object has to be rendered.
I guess this is what you mean by global and local shadows.
Taking this into account, the rendering of the flashlight shadow needs less pre-sorting calculation than the world shadows cast by objects and lights outside your view.
In other words:
The flashlight shadows should be less performance heavy than all the other shadows in world space as you'll only need to calculate the shadows of objects which are really visible.
In Doom3 it's the other way around.
Another thing that comes to mind in this context is that the original 2004 flashlight was always inside your view frustum. The new armor mounted flashlight is always outside your frustum which can, as you said, interfere with the near clipping plane unless they just moved the theoretical position of the flashlight from the upper right corner to the lower right and just skipped the rendering of the flashlight mesh.
But this would mess things up a little since the actual position of the light source on the armor and the light origin position for calculating the shadows would differ, giving inaccurate results.