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.
I'm not sure if I like that state of affairs. It feels like eroding goals or a capability trap.
TDD/CI/CD is critical and these are part of the culture at Pivotal.
Edit: a particularly poorly placed lack of negative.
In the same spirit, the longer you keep code out of trunk/master, the more risk you have and the more difficult it is for people to do refactoring. If you make large changes over a whole week, then you end up with difficult integrations. Even if you aren't doing true CI (i.e. actually integrating your code with everyone else's on a continuous basis), it's important to limit the amount of time your branch is held out of master. If you have a 2 week sprint and you have 1 week stories, you will almost certainly fail every single sprint (been there, done that ;-) ). The only way for a sprint to succeed is if the vast majority of stories are small enough that you are unlikely to start it without finishing it.
The funny thing about having small stories (around 10% of the size of your sprint) is that if you are doing them, then having a sprint end is inconsequential. You may drop a story or two from your board if things don't go as planned, but you will almost never start something and not finish it (especially if you prioritise stories by risk). So the main reason for preferring sprintless backlogs is because keeping the story size small is difficult.
In order to keep all your story sizes small, you have to be doing some things very, very well. First, you need to be doing your analysis very well. If you don't know exactly what you are building before you start, you will have wide variability in the amount of time it takes. It will also be very difficult to break problems apart because you aren't entirely sure where the good break points are. Second, your code needs to be very, very clean. You need to be refactoring literally constantly. The code needs to be simple in order to break your problem up easily. This requires a lot of iterations of design in all of your code as the code grows. All of this actually feeds back to the preference for CI over CD.
It's not a system that a lot of teams will prefer to use, but it has definite advantages. My experience has been that the potential is quite a bit better, especially over time. You need a team that is completely on board, though. It is especially difficult for PMs who usually don't want to think about problems in as much detail as is necessary for this system to succeed. However, I would encourage developers to keep an open mind because when it works, it works amazingly well.