It's also interesting in vanilla FreeBSD, so such an option sounds at least plausible.
I don't see a significant use case. I'm one of the people who've been deploying jail workloads basically since phk introduced them, and they're not real mainstream. It is more usual to have a shared shell box or other multiuser environment where there is actually significant risk in the main host environment. By comparison, a lot of the time when you've put something in a jail, it's already isolated, which means you don't really have a significant risk of an intruder trying to break out of a jail.
As for performance penalties, how is that looking for your (customers') workloads?
We'll have to see when a patch becomes available.
Back in the '90's, I created the earliest example of an appliance-version of FreeBSD that I'm aware of, which Andrzej Bialecki took and morphed into PicoBSD, which eventually led to NanoBSD. I've been a fan of small appliance-style devices for many years, and this is reflected in the system designs I've done. I do not like the monster, complex, unreproducible systems that many people seem to run. Most of the workloads I deploy these days are in independent VM's, and usually part of the design concept is that it is possible for someone to break into one of my hardened systems, but that this should not give them "keys to the kingdom" - that is, free and easy access to other systems. In as many cases as I can reasonably manage, workloads are running inside a /bin/sh-less jail on a single-task VM, which means "wicked hard to break into," but I still assume that'll happen eventually, and the rest of the systems have to assume that this is a possibility. It's the whole "plan for it" thing. So for a lot of the things I run, this whole thing is an exercise in near-pointlessness. But for other stuff, especially shell servers, it is definitely a concern.
FreeNAS has the potential to suffer some performance hits. Protocols such as NFS and (thankfully) iSCSI run in the kernel, but Samba is a big userland issue.
