On a project? Sure. I'm a big fan of blameless retrospectives as a way to maximize quality. But that only works in the context of a quality-oriented culture that is strongly focused on continually improving safety.

However, a) none of that was true here, and b) in the wider societal frame, I think blamenessless must not always trump accountability. When we're talking about egregious negligence leading to death, I think naming the culprits is the very least we should do.

I can see why you would say that, but isn't classical engineering a counter example? Professional engineers have a culture of accountability and responsibility. No system is perfect, but (to my eyes at least) classical engineering works safely without a culture of blame.

Preferable to the "mistakes were made" fog bank of diffuse nonblame. People respond to incentives whether cash or heads on pikes.

A culture of refusing responsibility is better how?

The opposite of a blame culture is not a culture of refusing responsibility, but a system where you look for problems in the process when a fault makes it into the final product. It's always a mixture of specification, implementation, and QA that makes mistakes possible. Putting the blame on the engineer is not very helpful, it does little to prevent future problems. Trying to figure out how it was possible that an implementation bug made it through QA allows you to prevent similar mistakes in the future (at least if you're lucky).

Just to be clear, I'm not putting the blame on the engineer. Many people are responsible for this failure. What I'm saying is that the engineer is one of the responsible people, and that as fellow engineers we should be especially concerned with making sure that responsibility is correctly performed and has appropriate accountability.