...

...

. What I am worried about is mistakes and oversights that slip through testing and then cause random or even attacker-controllable crashes in production

Why would this not be the case even with SCTLR.A bit set? I'm not seeing the relation between the crash and SCTLR.A bit. If there are oversights that slip through testing and an attacker can cause a crash, there is vulnerability/bug. If there is something that slipped through, that causes a data abort(perhaps address not mapped in the translation tables), would we turn off the MMU ?

Well, my assumption is that performing an unaligned access cannot be a vulnerability. If you have examples to the contrary please let me know, but as far as I am aware letting an unaligned access through should always work and will always result in the behavior the programmer intended (other than maybe contrived cases where device address space is mapped with a non-Device memory type, which is already very wrong for plenty of other reasons and should never happen). The only negative consequence is that the access may take slightly longer than if it were aligned. I do understand the desire to be able to shake out unaligned accesses during development and testing, but at least in a production build I think taking that performance hit would always be preferable to a crash.

I don't think the comparison to a data abort works because obviously with a data abort the program usually can't just continue and still assume its internal state is valid.