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.