ZFS terminology is different because what ZFS does under the hood is different. While ZFS supports striping across individual storage devices, (NVMe or SATA SSDs), it is not the same as RAID-0. Thus, ZFS uses the term “Stripe” when describing such a vDev device, or group of devices.
ZFS Striping is individually written group of storage sectors to a single storage device. The next selected storage device is not guaranteed to be the next one. ZFS will select the next Stripe storage device based on most free space. This is to balance the space across all vDevs.
Another reason for irregular writing of Stripe vDevs is that ZFS considers Meta Data, both standard, (like directory entries or extended attributes), and critical, (like free block lists and top of the Merkle Tree), as more important than regular data blocks. Thus, ZFS by default keeps 2 copies of standard Meta Data and at least 3 copies of critical Meta Data.
These extra copies of Meta Data are by default written to different vDevs, (if possible), than other copies. Thus, for standard Meta Data, they would be written to 2 different Stripe vDevs, in this case. And for critical Meta Data, 3 different Stripe vDevs.
So, ZFS Striping is NOT RAID-0. Nor similar to the way RAID-Zx striping works.
Perhaps it would be nice to have a RAID-Z0, without any parity, to accomplish very similar RAID-0. However, without the ability to add parity to a RAID-Z0 vDev, such a vDev type would have limited appeal. (And of course, if you could not expand the vDev like normal RAID-Z1/2/3, that too would limit the appeal.)