Stateless code makes for boring programs, but stateful code can be difficult to roll back.
As a toy example, imagine a database with columns for `first name` and `last name` and an update that combined them into a single `full name` column. That's going to be tough to revert for users signing up with just their full names.
While that would certainly impact production, it would be a bit strange for development environments to be stateful in the same way. Those not immediately involved in dealing with the stateful issue seemingly should be able to continue with their work away from production systems just fine.
Although in this case the build broke because the last committer didn't have authorization to deploy to production. The "fix" was giving him permission to deploy in the future. It is not clear why the developers going about their regular day wouldn't naturally resolve the broken build.
As a toy example, imagine a database with columns for `first name` and `last name` and an update that combined them into a single `full name` column. That's going to be tough to revert for users signing up with just their full names.