Interesting discussion of an interesting proposal.

Indeed guarantees are always subjective, and even many security experts
look at things from an economic standpoint: how much protection can we
get for a given amount of effort.

VM security is extremely difficult to make airtight. Some analysts say
the JVM is one of the biggest generally unacknowledged security risks
around the world. A lot of holes are found, and it's on so many devices
that are patched late, if at all.

Closest comparisons to this SRFI that spring to mind are the Dhall
language (basically an extremely restricted Haskell for writing
configuration files that are not supposed to have side effects) and
OpenBSD's new pledge() system call which can be used to disable all but
the given groups of Unix syscalls for the remainder of the life of the
current process (e.g. programs that don't use the network can disable
all socket operations).

OpenBSD's stance was precisely that while there are fancier security
frameworks with fine-grained configurable policies, they are so
intricate that people won't use them as intended. pledge() buys a good
amount of protection while being so simple that programmers will
actually use it. Perhaps you intended to make a similar argument in this
thread, John? That the SRFI provides a simple protection that is worth
its small cost and should be combined with other precautions.