Continuous integration originally meant that there was a single physical developer workstation that was considered canonical, and to get your work into source control, you would export a patch, walk over to that machine, sit down, merge your patch, run the tests, do any small changes you needed to get the tests to pass, then commit. If you couldn't get the patch working quickly, you would revert, and go back to your own machine and keep working on it.

Changes were serialized by the fact that only one pair could be sitting at the CI machine. Changes would only go into source control once the tests passed. Master was always deployable.

I once used a slightly more comfortable version of this process where you did the merge and commit at your own workstation, but there was a physical token that had to be taken before doing that, so that merges were still serialized. That worked pretty well!

The transition to the modern approach of just yeeting your changes into master and waiting for CI to go red after the fact constitutes a decay of this original practice. I don't think it's a deliberate evolution.