Having done my workstation, I did a server next, and the server taught me a few things the desktop didn't. The headline reason is the same, snapshots and rollback, but on a box you can't easily walk over to and rescue, the failure modes matter more. Here's what I'd tell myself before starting.
Lay the datasets out properly the first time
The temptation is one big dataset for the lot. Don't. Split things that have different snapshot and rollback needs into their own datasets so a rollback of the OS doesn't drag your data back with it.
rpool/ROOT/default -> / (boot environment, rolled back together)
rpool/home -> /home (separate, you rarely want to roll this back)
rpool/var/log -> /var/log (separate, never roll logs back with the OS)
The principle: if you'd want to roll one thing back without the other, they belong in different datasets. Rolling / back to before a bad upgrade while keeping the logs that tell you what went wrong is exactly the situation you're building this for.
The bootloader is the awkward part
Your bootloader has to understand ZFS to find the kernel, or you keep /boot on something simpler. I went with a small separate /boot on plain ext4 because debugging a bootloader that can't read its own root filesystem at two in the morning is not my idea of fun. It's slightly less elegant. It's considerably less stressful.
Don't put swap on a zvol
This is the one that bit me. A swap zvol looks tidy but can deadlock under memory pressure, because ZFS itself wants memory to write out swap, exactly when you have none to give. Use a plain partition for swap. I learned this from other people's bug reports rather than from a locked-up server, which is the cheap way to learn it.
Set up snapshots before you need them
The mistake is to set this up and then forget to actually take snapshots, so when something breaks you've got the machinery and none of the safety. A simple periodic snapshot with retention, hourly kept for a day, daily kept for a fortnight, costs almost nothing and means a rollback target always exists even when you forgot to take one by hand. Tools like zfs-auto-snapshot or sanoid handle the policy for you. I run sanoid with a modest retention and let it get on with it. The point of root on ZFS is the safety net, and a safety net you have to remember to deploy is no net at all.
The rest is unremarkable, and unremarkable is the goal. Once it's up, zfs snapshot before anything risky becomes a reflex, and the first time a rollback saves you a rebuild, the weekend you spent setting it up stops feeling like an indulgence.