If you are prioritizing expandability later, then that pool config makes sense. Several discrete smaller pools is more upgradable than one large pool.
Keep in mind that you are trading what amounts to 17-20 TB of raw capacity, from about 10-13 TB usable using one large pool with 2 disks of redundancy down to ~9-10 TB with 1 disk redundancy per pool.
Personally, I do not like the idea of expecting to do maintenance later so I would prioritize redundancy. Raid5/RaidZ-1 scares me. I would rather do 3-way mirror than any 3 disk Raid 5/RaidZ-1, but this is your call, especially if you are fine doing maintenance.
At this point, I would recommend two things:
1- “Hot spares” is a reserved term when talking about RAID configs. It means the array exists independently of the “hot spare” and there is an additional disk or series of disks that can become part of the array if a disk in the array fails. Hot spares do not provide capacity to the pool. They also do not provide additional redundancy while they are not actively part of the array.
I think you meant to use the term “redundancy” or “redundant disk.” These disks are actively part of the array and have data on them. They are not hot spares. These distinctions matter when reading up on the ZFS documentation.
Do not use hot spares. Hot spares accumulate wear while merely powered on. On + unused = worst of both worlds. Either do cold spares (off and unused to minimize wear) or just make them part of the array as redundancy is their intended purpose (on + used).
2- I am assuming you are still going to be using RaidZ instead of mirroring+striping since speed is not much of a concern. Then, because RaidZ capacity benefits enormously from additional disks, roll Tank3 (mirror) into Tank2. This will increase the capacity and redundancy of the Tank2. The 1TB disks in the vdev should be replaceable with a single 2TB disk later on should either fail. IDK what the syntax would be for that however.
Or, if you are going to replace the 1TB disks right away, why bother including them in the server at all? Find some other use for them. This is again, a maintenance issue. If you do not mind doing constant maintenance, upgrading the pool later, 3 distinct pools with decreased redundancy is fine, but I would rather never do maintenance.