"Correct" is the key word, I think it is important to make sure that people feel not attacked and your take on it is mostly correct but this is mostly in context of opinions and nit-picking. Actual failures need to be owned publicly.
I think a missing element in what I said is that I also fully believe that if I fail at something, it is my responsibility to inform the team rather than wait for someone else to levy blame. ("My apologies, I realized I misread the ticket and wrote the logic expecting X when it should be expecting Y." or "I created the typo there, I'm sorry, will fix by XX AM.") If the team works in that context, then you don't need to correct in front of the team as the person who failed would inform others and use it as a learning moment for all. This also kills the ego problem a little.
I also think failures tend to be systematic in nature and are rarely owned by a single person once you get to the bottom of the 5 "whys". We use Github BATS in PRs now, this fully killed the whole rubber duck of shame culture in our engineering division. While someone breaking the build used to be a singular responsibility, now it is a shared responsibility of the reviewer and tooling and nobody else's build gets broken by bad code. It is easy to blame the person who wrote the code but that excuses those that create the systems and culture.