I don't have a report to link to, but experience certainly says so. I'll make another broad statement: I don't think most experienced engineers would argue with me that the more quickly changes are made to software (which implies a large volume of changes as well) introduces less stability over time. Or certainly greater risk.
I would also point out that the parent thread is good evidence. My point was that SemVer didn't save them from making a mistake, nor did the lack of SemVer save Underscore the other night. Volatility is what bit people.
When old software has bugs that don't get fixed, that also poses risk (see many recent high-profile security flaws). People just tend to overlook these problems more.
Simply waiting between commits reduces the rate of change, but does not increase the thoroughness of QA. In terms of defects, a project with very good, careful QA (any remotely acceptable strategy for reducing defects) will be at an advantage at every rate of change to a project which is just people pushing to master.
Some forms of careful QA impose a lot of latency between the decision to change and the change actually hitting, but that doesn't necessarily imply a reduction in throughput of changes per unit time, and it isn't the time which is reducing the defects but what is being done with that time.
I think that depends on your workflow as much as anything else. There are ways to mitigate the risks of moving fast, unit testing, integration tests, sanity checks, rolling deployments, service layers (micro services), etc...
By establishing the mindset that what you are pushing into master will make its way into production, you look at things very differently, with a much more critical eye. There are waterfall designed systems that took years to develop that made it to production with bugs... is a bug that breaks things for 5 minutes worse than one that sits for months, or a security fix that isn't deployed and might be exploited because your review process takes weeks?
