Your line of questioning is a bit odd in my opinion. You say that many people use swap with ZFS but really, ZFS has little to do with it because even with UFS it is recommended to use swap
I'm running FreeBSD on an older PowerEdge which had 2Gb memory and I set up a 4Gb swap. Within the ZFS pool:
Code:
peter@zefiris:/home/peter $ zfs list zroot/swap
NAME USED AVAIL REFER MOUNTPOINT
zroot/swap 8.25G 34.1G 8.08G -
It's now 8 because some things changed over time. When it was still 4 I did occassionally run out of swap space but that only happened when I was building large ports, such as
lang/gcc8 or
devel/llvm70. The solution was to add some extra swap; I used a swapfile which I stored on a local UFS filesystem.
Still, this isn't really interesting because ZFS had little to do with it. After discovering something wrong with some of my memory banks I even ran this system with 1Gb of ram, still utilizing a large zfs hierarchy, and never ran into any serious issues. Not even whilst running an X environment.
What is much more interesting, in my opinion, is the question if you'd set up swap inside your ZFS pool or as an external partition, because there's something to say for both methods. If you add your swap to your ZFS pool while that ZFS pool is a mirror or raidz then this means your swap is also going to get propagated across the different vdevs, which could cause a little more stress on your system.
So with that in mind it might be more beneficial to use a separate swap partition. This would also come in handy if you had to perform extensive maintenance or recovery tasks from a rescue environment: that rescue environment would be able to utilize that same swap space as well (if your ZFS pool gets damaged then it obviously wouldn't make sense to try and use its included swap space).
Of course if you add your swap space to your ZFS pool then you can easily resize it at a later time when needed, you wouldn't be able to do that with an external swap partition.
Finally: a system doesn't really go "b00m" when it runs out of swap space. The kernel will detect this problem and kill any problematic processes to try and solve it. In my example of compiling
gcc8 it simply killed the build process and that was the end of that. Everything just kept on running without issues, even my X environment (which made this problem tricky to find at first because there wasn't any mention of swap space in the build log, only when I examined
dmesg did I notice the obvious).