It’s a bit of both for me.
Jails have functionality beyond Apps. For example, it’s pretty likely that iXsystems will increasingly lock down OS / TrueNAS. In turn, that will likely start to break things you can currently do at the OS level.
Hence, you’re likely better off creating jails that are fully segregated from the OS for many tasks like scripts, etc. Jails will continue to exist on your datasets vs. being at greater risk of critical settings / packages / etc. being overwritten inside the boot pool.
For example, I found that my iocage folders were pretty devoid of anything useful when I transitioned the NAS from core to scale so I’m glad in now have jails that I can back up separately.
Then there is the issue of cruft. For example, my CORE boot pool included @dan’s excellent deploy freenas script to allow a wider scope of DNS providers than route 53 for SSL deployment to TrueNAS.
SSL deployment goes beyond just acme.sh, it also includes the need for socat snd other packages. Some
of those items may be incompatible with the OS or require the use of a different version of the enabling software than iXsystems includes in its version of Linux.
In a jail, you can have whatever you need, making similar changes inside the boot pool you are potentially risking the stability of the NAS.
These days, I save scripts that require additional software installs into a dedicated jail and once those scripts are no longer needed, delete the jail rather than try to return the underlying boot pool back to a “pre-deployment” status. It keeps everything cleaner.
