There should be a "Safety Value" that if it is divide by zero or array out of range then the safety value is used.
I'll say it again with vague examples.
Someone has a process where loss of lubrication to a bearing would cost millions of dollars.
Someone else has a process that can harm or kill someone if it does something unexpected.
What are the correct "Safety Values" for those situations? Is there any way the PLC manufacturer can know those values when they sell the un-programmed PLC? Those are rhetorical questions because the answer is "Of course not."
One viable alternative for the PLC mfr is to tell the programmer that certain cases will cause the PLC to fault, and what a fault means; along that line I think A-B's design decision is most likely about liability, specifically pushing liability for each process from the PLC mfr to the owner of the process.
Several times a year, maybe once per month, there is a post about scaling on this forum. There will follow replies explaining y=mx+b et al., which many of us have understood since grade school. But I often ask myself why has that OP been given that task when they don't understand summat as basic as that, and what other potentially critical knowledge don't they know? From a business perspective A-B has to ask itself the same question about the purchaser of every PLC they sell; to do otherwise would be business suicide.
The only thing worse than a PLC not doing what I want it to do is when it does exactly what I told it to do.
I think of myself as a half decent programmer, but when my brother told me Siemens lets you write to memory off the end of an array, my jaw dropped, because I have accidentally frozen and rebooted computers doing that*; fortunately there was nothing physical involved to damage.
It's about liability; if you think it's so inconvenient that a different choice should be made, you are probably over-estimating your own programming skills**, and you are certainly over-estimating mine.
** The fact that you consider faulting on programming errors an issue certainly supports this
At a minimum, every competent application programmer will consider what happens if the PLC loses power; the plan for that will cover the faulted case. I'm not saying there are no scenarios where it's inconvenient and/or unnecessary to have a PLC fault on a programming error, but A-B has both chosen to make the programmer find them and provided a workaround for them; I don't think it is reasonable to ask for more.
* Timex 2068 72kB computer, writing bit pixels on a line to graphics memory, flubbed the edge of display check and continued into system memory.