Since the days are over to part very large drives into smaller pieces the filesystem can handle with its address range, apart from the partitions the system comes by default installation on the booting system's drive: swap, boot, efi, and /, there is no much sense in partitioning further anymore, unless you're going to use additionally different filesystems, e.g. for multibooting different OS, like having a NTFS partition for Windows, ext4 for Linux, or having a FAT32 partition for whatever else reason I cannot think of, or something like that, which on a server is very unlikely anyway.
So, no, I see no sense in doing partitioning.
What makes sense is to have separate pools on separate drives.
When using ZFS you don't think in partitions or drives anyway, but in pools.
It makes sense to have separate pools for different stuff, like to separate /home/ or other data on own pools separated from the system. It also makes sense to have own drives for pools. A ZFS pool consisting of more than one drive not only pools the storage of each drive to the pool, but above all brings redundancy against hardware failure. Having a separate pool for data also gives the possibility to move the whole pool to another machine, instead of copying everything between machines.
If I had to recommend a layout for a small to medium server I'd say use one small drive (128...256G) for the system. Default's efi, swap, boot, and / partition come by default installation on that drive, but don't create any extra partitions for /var/ and /usr/ - makes no sense. Maybe place /tmp/ with tmpfs into RAM.
Then add a couple of large, equal drives for the storage, like >=4 drives of >=1T capacity each. Create a raidz2 or raidz3 pool with them, and place /home/ and "/allmydata/" on it.
For a FreeBSD only workstation I'd say: one 256...512G NVME for the system, and a mirror pool of two 1T drives, containing /home.