The purpose for the raid system is redundancy. The servers will go offshore to some unmanned installations so redundancy on the disk system is a must.
I absolutely would not run something like that without redundancy, but getting the redundancy from zfs's raid is better in a lot of ways than getting it from dedicated hardware. It is more flexible, and smarter. For example when rebuilding after replacing a drive with a hardware raid controller, the raid controller doesn't know what is free space, so has to rebuild the entire drive, but zfs does know what's free, so it doesn't need to rebuild free space.
Hardware raid only reads from the parity block to do rebuilds or if one of the other drives reports a read error. If a drive reads the wrong data, but doesn't report an error, then you get corrupted data, it isn't repaired from the parity. On ZFS every read is checked against a stored hash to verify the data is good, so in case a drive returns bad data ZFS will find out, it will recover from the parity block, and return only good data to your program (and will write it out to fix the bad version on the other disk).
And as SteveITS hinted at above, you can move the redundancy up the stack with Ceph to have what looks like a raid spread across 4 or more servers, so the redundancy covers not just a failed drive, but failed servers. This is much more complicated and adds requirements like fast networking, but might be a good choice if you are building something with multiple proxmox hosts.
