To illustrate my point, I've taken a couple of grabs from the analysis feature of MegaPEG.X Pro Demo, as applied to a DVD title (popular TV show).

 

If you look at the Figure to the left, you can see a light green circle around a scene change. Here we see the familiar IBBP GOP pattern taking a scene change one frame before the I-frame. Based on the popular notion, we would expect to see some significant variation in the sizes of the BBP groupings to either side of the I-frame. But it is clearly not the case. Instead, we see that the B frame which sits directly on the scene change boundary is no larger than the earlier B-frames which were simply a part of the flow of the previous scene.

 

Here's another example from a rock video. This particular video is simply filled with great examples. Ironically, the hardware MPEG-2 encoder that compressed this particular video DOES in fact, use I-frame injection. In this case we see that the scene change occurs directly after a P-frame. Notice that the P-frame derives its compression efficiency from the earlier-in-time (leftward) P-frame, and the BB pattern that follows is compressed against the later-in-time (rightward) P-frame.
It is clear from the pattern of frame sizes that this poses no difficulty for the encoder whatsoever.

The mathematics of bi-directional motion compensation eliminate the need for placement of I-frames at scene changes. In reality, we want to use the longest GOP structure possible (as provided by the constraints of the profile), thereby reducing the cost of I-frames, which are the least efficient to encode (require the most bits).