Jag skulle inte döma det så - prova båda (linux har inga problem att köra flera flera olika filsystem samtidigt), stressa med olika skrivlaster och med användning ser vilken du trivs bäst med.
En RAID måste du ändå ha regelbunden backup på och speciellt med ZFS då det inte är mycket att laga eller försöka rädda data ur den dagen det havererar.
Själv kan jag omöjligen undvara BTRFS snapshotmöjligheter i backupsammanhang när man väl smakat och förstått hur bra de är och att det är helt oberoende volymer som skapas med snapshot som kan tas bort i vilken ordning som helst och var och en kan modifieras hur som helst i olika riktningar utan beroende eller påverkan av någon annan subvolym och har svårt för ZFS hierakieska motsvarighet med beroende mellan snapshot-generationer där man inte kan rensa i snapshoten i valfri ordning för att återskapa diskplats, modifiera olika versioner av snapshot fritt och kunna ha schemalagd utglesning av backuper beroende på hur gamla de är... hade open source ZFS någon gång fått tummen ur och implementerat 'reflink' som orginal solaris ZFS faktiskt har - så hade det hela varit lättare att svälja - men av någon anledning är opensource-kodarna för ZFS varit extremt reluktanta att implementera det trots att det tjatats om det i över 10 år... med 'reflink' så hade man kunna kopiera mellan dataset där bara ny metadata skapas medans nya metadatat fortfarande pekar på datadelen av filerna som finns i orginal dataset och istället för flera timmar kopiering där all data skall läsas och skrivas på ny ställe i lagringen så hade en ny dataset som kopia av instans i orginalets dataset kunna skapas på typ 30 sekunder till ett par minuter för typ 1 miljon filer på 1 TB sammanlagd storlek som man kan göra i BTRFS och det är bara nya metadatat som tar extra plats på disken i ZFS, inte dubbel kopia av allt (när man inte har sektordedupliceringen påslagen - och det av flera skäl)...
Ett råd är att inte använda ZFS på vdev baserade på flera externa USB-diskar samtidigt, dels av att en del modeller stänger av spindelmotorn efter en relativt kort tid inaktivitet och uppspinningstiden är farligt nära 8 sekunder och är responstider över detta sparkas disken direkt ut ur ZFS-RAID:en, och speciellt inte dagens versioner av externa USB-diskar då de mindre än 8-10 TB är SMR-diskar och de kan vara 'borta' mer än 20-30 sekunder utan respons när de 'nödstädar' sin PMR-del om disken inte får pauser i avseende skrivning/läsning så att de hinner städa ändå - och sådan läge när disken aldrig får paus är vid synkning/'resilver' av RAID under många timmar, ja hela dygn och beroende på skrivmönster som där man backar och skriver om redan nys skrivna sektorer under synkning/resilvering kan en sådan PMR-område i en SMR-disk fyllas upp väldigt kvickt (det är det mönster som gör att NTFS-filsystem tar ihjäl en SMR-disk tämligen fort när man kopierar över större mängder småfiler på en gång utan paustid).
När det gäller 'kritik' för olika filsystem - kolla när dessa skrevs då de som är flera år gamla har inte samma vikt som de som är mindre än 3 månader - då menar jag nya saker och inte upprepande av samma saker som skrevs 3 år innan då det trots allt utvecklas och putsas på båda filsystemen hela tiden och stora fel som har konsekvens i praktiken åtgärdas ganska snabbt - sedan finns det filosofiska saker på var som borde och inte borde - men det viktiga är om det har någon betydelse i faktiska utfall - jag har provat tex. BTRFS native RAID5/6 under typ 3 år med krånglande och utbytta diskar, bakgrunds deduplicering med bees hela tiden och den är inte sämre än tex. klassisk mdadm-RAID och vissa fall klarar sig bättre än mdadm-RAID vid tex. flera strömavbrott kort efter varandra och att resynkningen inte hinner blir klar mellan dess - eller kort sagt jag har förlorat data med mdadm-RAID men inte förlorat/fått korrupt data med BTRFS i native RAID5/6 under samma yttre omständighet med flera strömavbrott kort efter varandra.
Men det går givetvis att hitta ett syntetiskt felmönster som även kraschar BTRFS-RAID om man vill - men det är inget jag råkat ut för hittills.