It's amazing that (if I understand it correctly) the entire security of the system rests on the user not being able to execute arbitrary code. One wrong-code bug in the (privileged) compiler backend and it all falls down.
In practice, it doesn't matter so much, because IBM i is an (ever-increasingly fringe) server platform for business applications, so the odds of malicious code ever making their way on to the system is much less than for an OS used for more general purpose computing
But you are right, and in that it has something in common with sandboxing of Java applets, for example – which didn't work out as well as its inventors had hoped.
That said, although classic applications all run in a single shared address space, newer versions have added support for isolated per-process address spaces (teraspaces), which have in turn used been to add an AIX compatiblity layer (PASE). If you write your apps against AIX compatibility layer, you get process-based security just like you do on AIX. And in that layer you aren't just limited to calling (a subset of) AIX APIs, you can also call into IBM i native APIs which don't exist on AIX – albeit at some performance cost, since the call has to be marshalled into the single shared address space.
IBM's original JVM ran in the classic single shared address space, and was deeply integrated into the OS. Then they replaced it with J9, their JVM for AIX/Linux/Windows/etc, and J9 runs under the AIX compatibility layer. Given they encourage Java for developing new apps – a lot of apps now contain a mixture of legacy RPG/COBOL/etc code along with Java code to implement web UIs and SOAP/REST APIs – more and more stuff is running outside of the shared address space.
