A robot is not just software with a bug budget
Most software failures cost money, time, or embarrassment. A robot failure can break bones. That distinction sounds obvious once stated, but it changes the entire engineering process around a robot in ways that are easy to underestimate if your background is in software. A web app that mishandles an edge case ships a patch the next day. A robotic arm that mishandles an edge case while a technician's hand is inside its workspace does not get a patch, it gets an incident report, and possibly a person who never fully recovers. That asymmetry, most software mistakes are reversible and most robot mistakes involving human contact are not, is the entire reason a separate discipline of robot safety engineering exists at all.
This is also why 'we tested it and it worked' is not sufficient for commercial robot deployment the way it might be for a software feature. Testing shows a system behaves correctly under the conditions you tested. It cannot show what happens under the conditions you didn't think to test, and for a robot working near people, the conditions you didn't think to test are exactly where someone gets hurt. Safety standards exist to replace 'we hope this is safe' with a structured, auditable process for actually demonstrating it, one that doesn't rely entirely on one engineering team's imagination for what could go wrong.