These are the
personal opinions of a professional systems architect who has worked with ZFS almost since its inception and under Solaris, OpenSolaris, OpenIndiana, FreeBSD, and FUSE (Linux, OS X). I'll stop credentialing now, since it won't make a difference anyway.
One of the design goals for ZFS was to abstract as much functionality away from the low level as possible. Consequently the way encryption is handled in Solaris 11 (and onwards) adheres to this philosophy since essentially encryption is managed as a "plug in" much the same way as compression and de-duplication. The devil-containing details are in the key management, as always with anything crypto-related. If you want to see how easy it is look here:
http://www.oracle.com/technetwork/articles/servers-storage-admin/manage-zfs-encryption-1715034.html
Unfortunately with the Oracle purchase of Sun that work did not make it to Open Source before Oracle slammed the door. Until such time as the work is re-done for
zfs 5000 or btrfs reaches maturity and functional parity, we're stuck with the current work-arounds.
FreeNAS does not adhere to the ZFS architecture for cryptography but rather interposes a virtualization layer between the raw disk blocks and what zfs thinks are disk blocks. In theory this is transparent. In practice you're lying to ZFS just as badly as if you were using hardware RAID and adding a risk to the zpool integrity that is on a par with not using ECC memory. (Again, personal opinion, others will disagree.)
This does not mean that I am anti-cryptography. Far from it, I'm a firm believer that data at rest should be encrypted AND compressed by default because CPU cycles are cheap if you don't encrypt everything if you do have sensitive data that is encrypted you might as well label it "My valuable and/or incriminating stuff". So my (again personal) opinion is that you should encrypt at the file level or if you must have an encrypted filesystem have your client OS encrypt either a ZFS volume or something like a
sparse file. In addition this will ensure the data is also encrypted in transit over the network from client to FreeNAS and FreeNAS is absolved from key management.
Wether you actually
need encryption or not is a trickier question and a lot more personal. However I'd raise the issue of "rubber hose decryption", ably illustrated by xkcd:
The rubber-hose-wielders can be the usual three-letter agency suspects, thugs hired by the Ex, etc.
Basically the principle is that you really only need good enough encryption to the point that it's easier/simpler/cheaper for a "bad actor" to switch to "rubber hose" decryption. Beyond that I suggest looking into steganography and dual partitions with dummy lures that can be sacrificed under duress. e.g. a lesser offense (preferably embarrassing) is exposed by one pass key, the much more serious offense data is unlocked with a different key and looks like noise in the empty space until unlocked. If you're in that level of situation on a regular basis I wish you and your kneecaps the best of luck.
tl;dr: Current FreeNAS GELI encryption is a Bad Idea IMO. Do it a different way.:p