What wasn't very clear to me in reading this paper was just how many different applications really needed this kind of flexibility. I can think of a handful in my professional experience that might benefit from this, but the list of examples is pretty short. The first project that would benefit from a system that (as much as possible) exposed physical resources directly without much in the way of abstractions on top is some very high scale server systems I've worked on in the past. Many operating system behave strangely under very high loads, or when maintaining very large numbers of sockets. Our group would try to get help from OS experts in understanding why our version of Solaris was being so stranger when maintaining tens of thousands of sockets concurrently. If we had an OS that exposed physical resources without abstracting them away (and we got to choose what libraries we wanted to implement the higher level abstractions) then more of these types of problems would be debuggable.
It was also intesting to see the limitations the hardware imposed on the ideas the authors were trying to implement. The X86 architecture didn't make it as easy as they would have liked to allow individual applications to modify the virtual memory tables since many table operations are handled in hardware and didn't adapt cleanly to their design principles.