It seems that you are using geli here for verification (checksumming) of the sectors (perhaps also for encryption, I didn't bother decoding your command line fully). This means that for every sector of data that is stored, geli will also store (on disk!) the checksum, in this case a 256-bit (or 32-byte) number. What is a "sector"? It is the smallest block of data that can be atomically read or written, both at the interface between geli and the disk, and between whatever file system sits on top and geli.
Now think about how geli will do verification: When the file system wants to perform a read of a sector, geli needs to first go to the disk and read the actual sector data, and then it needs to again to the disk (in a different place) and read the 32-byte checksum. So it needs to reserve some space on disk for the checksum, at least 32 bytes per sector. But reading is easy, writing is hard: When wanting to do a write, geli first writes the sector to the disk, and then has to have a place to write 32 bytes. Where would that place be? In theory, geli could pack 16 such 32-byte checksums into a single 512-byte sector. But remember that at the disk interface, you can only read and write whole sectors. So to modify 32 bytes within a 512-byte sector, geli would have to perform a read-modify-write cycle on the disk. That is hard (for a variety of reasons, not the least of which is that preserving ACID properties with non-atomic writes is hard). So what geli probably does: it uses a whole 512-byte sector for the checksum. If you are using 512-byte data sectors at the interface between the file system and geli, that means that for each data sector a whole other sector will be "wasted" (one could also say productively used) for the checksum, and there is your 50% efficiency. When using 4096-byte sectors, that is reduced to one 512-byte checksum sector (probably containing 8 32-byte checksums) for each 4096-byte data sector (=8 physical 512-byte sectors), or an efficiency of 8 out of 9, meaning 89% or 11% loss.
May I ask a question: Why are you using geli checksums? Why not let geli do just encryption, and then run ZFS on top of it, and use ZFS checksums? Because ZFS has interestingly complex metadata structures, it can store file-level checksums more efficiently than by using a whole sector. And you move the checksum mechanism higher up in the software stack, thereby catching more problems.
