I do not think that the lock is a reasonable comparison here, because exploitation of software scales so so so much more effectively than picking locks. One exploit easily scales to millions of devices. So the harm caused by vulnerable software has a much higher ceiling than the harm caused by a weak lock.
If I install software that was written in C++ on a device I own and it processed untrusted content then I put myself as fairly major risk of all sorts of harm. There are only two resolutions for this problem:
1. No more memory-unsafe languages on security boundaries.
2. Extremely effective sandboxing and process isolation.
#2 has proven very hard. But we know how to do #1. We just need to spend the effort.
I don't know that it's particularly possible for a developer to truly understand all the possible impacts of an error in their program.
I'm not sure what the best way to handle that uncertainty is. Assuming all failures are critical would do the job, but certainly isn't free. However doing something like is suggested here - somehow requiring safer languages - might be a decent middle ground. The cost of using languages more built-in safety features is often not very high. Actually often such languages claim that those features make them cheaper to use.
If a building collapses, it's likely that people will die.
The consequences of failing software can be mere annoyances depending on the context of its use.
Obviously certain industries that use software have much more dire consequences of failure though (eg. large machinery, transport, health care).
I think one could come up with all sorts of analogies that fit or don't fit, such as, applying a similar argument to door locks. Why should it be legal to use ordinary keyed locks on houses when they are so easy to circumvent with basic lockpicks?