I would be willing to bet this is simply due to the camera changing modes back and forth between live view, actually exposing a photograph, and returning to live view.

1. In live view, it sounds like it stops the aperture down to where it should be.
2. When you take the shot, live view "exits", so the camera is set back to normal. That would reset the aperture to normal and close the shutter.
3. However, since you are actually taking a photograph, it then has to restop the aperture, expose the sensor, then restore the camera back to its default settings again.
4. Finally, since you were using live view, it starts up live view again, which will open the shutter and set the aperture appropriately for your live preview.

I've done some basic embedded systems programming in the past, and you often run into limitations that are tough to overcome given the nature of the hardware you are working with (which is usually very, very limited.) Its fairly common and pretty easy to simply use a basic state machine and workflow to track what "mode" the system is in, and have a reset action take place when you transition between states. In the case of a camera, you would want to make sure that everything is set back to "zero" or "default" state before exposing, so the logic that actually performs an exposure is working from known good starting values. It requires more registers, more memory, more constants, and more logic to share 'state data' between one 'machine state' and the next, when generally state machines are supposed to be globally data stateless in the purest sense of the word.