However, this isn't a necessary design. An operating system could instead accept programs in a 'safe' higher-level language. The OS would include a trusted compiler. Then safety can be achieved by construction instead of by hardware support.
Compiled binaries could be cached so we don't need to recompile every time. It is also feasible to configure the OS to use a trusted remote cache, i.e. fetch signed binaries specific to hardware architecture based on a secure hash of the program and a set of parameters.
Existing programming languages would simply treat the OS's chosen language as yet another compilation target.
This approach has a lot of potential for performance because a lot of indirection can be avoided, and even inter-process communication can potentially be reduced to objects talking. However, I've only seen a few aborted attempts. I think the biggest problem is the huge heaping amount of work required just to get back to where we are today.
I read the whole piece as a reminder that there's no free lunch, and no silver bullet, only tradeoffs. (The part about OOP which was all the rage at the time seems to lack that balancing part, though. It ended up a tradeoff, too.)