Re: systems that are no longer "secure" but "immune."
Sure. But you can have systems where bugs effects are much more contained, and can't be used to mount attacks.
Take for example ROP. AFAIK, since the 80286, x86 chips could design segments as executable only (you can't even read their content from code, only the CPU can still load and execute it). Other segments could be readable/writeable, but not executable.
IMHO it would be very difficult to use ROP against a system which would use that 1984 technology. Combined with address space layout randomization, even reading the executable file won't tell you where it will be loaded in memory, and you would have no way to read it once in memory from user space (you'd need kernel code to create a readable segment for the same memory space).
Data code won't be executable, so even if you find the right byte sequences, they would be useless.
But no OS I know use these features. They set single huge overlapping segments, and the NX bit at the page level is stopgap that still can't block ROP.
Moreover the four ring model of the 80286 was clearly better than the two levels used by most other processor. It wasn't used because it was not compatible cross-platform code, and because every time code needed to "cross" a segment boundary, the access control checks (aka security checks) made it slower.
Back then performance were far more important than security - and we got here....
Now it's time to redesign CPUs, operating system and application so they work in an environment designed from the ground up to hinder many attack techniques ("immunity"), instead of trying to spot them and react.
Maybe bringing back some of those thirty years old designs, instead of removing them fully (hint: never let AMD design a chip - it too understands performance only, never security).