Plex accesses storage a lot and there is no fast option for exposing storage to a VM. The CPU overhead is going to be small, it's the constant back-and-forth across security levels that's going to kill performance.
Ah, I can confirm that that is the case if you host the Plex metadata on the pool. Plex especially generates boatloads of IO for it's metadata cache. On my mid-range library (~250 movies, ~2500 episodes of various shows) the thing is 18GB and has 161,188 files! I used to host the thing on my pool, and it soaked up ~70GB of disk space due to the overhead with so may small files.
After 2-3 iterations of moving ESXi Datastores around and trying out a SLOG device, I ended up tossing an old SSD I'd forgotten about (an OEM Liteon 256GB drive that came with a laptop) into my server and connecting it as a physical datastore (as opposed to an NFS share or iSCSI extent) dedicated to the Windows VM that hosts Plex, Sonarr, and Sab, and making all of these apps use it for their metadata/cache/temp drives. Plex now starts up almost instantly, the Plex metadata isn't soaking up room in my ARC, which can now focus on serving me my files, and performance has been GREAT. Turning on Drive Compression in the Windows VM has also visibly helped - I have CPU cycles to spare to compensate for IO inefficiencies than ESXi imposes. This setup has been fabulous for the 1+ year I've set it up this way, so I'll probably continue to use SSDs for VMs outside of FreeNAS to avoid most of the IO overhead, and use FreeNAS just for shares. For a small setup on a budget, this is simpler and more cost effective, IMHO, than trying to make ZFS perform well enough to host VMs well ($$$ RAM upgrades, SLOG drives, etc) , especially those that do a lot of IO. 256MB/512MB SSDs are peanuts nowadays, and many tech folks have extras from laptop upgrades anyway that are going to waste.
It also keeps pool fragmentation down - all the IO that the VMs are generating is NOT being done to the pool, but to an external SSD, so it keeps the pool healthier.