Maybe developers spend more time on reviewing and testing their code when they commit directly to the main branch, then when they know someone else is going to review tge code en perform the merge? How bad is a bug when it is caught the same day?
Maybe developers spend more time on reviewing and testing their code when they commit directly to the main branch, then when they know someone else is going to review tge code en perform the merge? How bad is a bug when it is caught the same day?
(I'd rather draw a line with code review being/not being a norm, rather than whether it's mandatory. It can be mandatory and still shit.)
And as you suggest, I would expect that trunk-based development leads to greater care for quality. Add to that code reviews that seem to improve quality even further. I don't see a contradiction here.
Also, what the data suggests is that, for good productivity, it may be more important to have short lead times (from development to production) rather than just "no mandatory code reviews."
If you can expect code review to be done just-in-time, you retain the context, limit the tax of context switching, avoid Zeigarnik effect (https://en.wikipedia.org/wiki/Zeigarnik_effect), etc. So I guess this may be a sweet spot reconciling two sources.