I like everything except the small blast radius point here. You can do a lot of damage in a short period of time with computers.
If you have a shorter period of time to produce a smaller change, are you more or less likely to have a smaller blast radius than if you have a longer period of time to produce a much larger change?
There are no absolutes, but we're talking about risk here, and risk is about impact and _likelihood_. Your impacts are going to be smaller and your likelihood of big blast radiuses are _less likely_, but not ruled out.
Having said that - a smaller piece of code is easier to understand, so there is more potential to notice problems.
However that depends on whether you do that diligence. And the dangerously false belief that the blast radius is going to be smaller because of change size rather than understanding works against you.
bug size * mean time to recovery
So if you release early, release often and keep an eye on your metrics, you stand a good chance of your blast radius being consistently low.
You won’t eliminate it, you’ll just be beating the team with rare and large releases that take an age to get through their release process.
Of course, if you can take your time and make small changes slowly, but release them quickly, you’re now doing even better, but there are few businesses where that’s economically viable: competitors will just get to product market fit quicker than you will.
What is the underlying mechanism that makes it so?
It’s a red herring. Risk is lowered because the code is understood better not because the code is smaller.
The assumption that each change carries an equal risk of disaster isn’t valid, because risk depends on your understanding of the changes and the codebase.
Risk is equal only in the case where the developers know nothing about the change or the codebase. In this case, fire the VP of engineering or equivalent.
Making changes as a series of small increments can just as easily lead to less understanding of the overall impact of the changes than a larger design process. Then you get a nice big failure from a small change. It looks like most of the changes were harmless when in fact they were all just building towards the one that caused the failure.