The setup made more sense when it was believed that HIVE would eventually have a high market price. Everyone is used to there being a maximum deliverable upvote (100% upvote) but there is also a minimum (0.01% upvote). We had some concerns that as Hive SBI grew, the minimum upvote value would exceed the desired 0.021 threshold and create weird issues. That has never happened because of HIVE underperformance, but it could still happen as HP grows.

There are also edge considerations around blockchain behavior. It was not possible for an account to upvote more than one post per block (I'm unsure whether this technical limitation still exists), so having multiple voting accounts bypassed this restriction. In practice we self-throttle so that RPC nodes don't cut off our access, so we rarely deliver more than a single upvote per block anyway. Being fast is less important with straight-line curation for the first 24 hour of each post.

Finally, there are legacy reasons. When the program was first begun, we did not have our own voting bot and we were using third party software that had a limitation of 100 target accounts scheduled for each voter. We were required to scale up to 10 voting accounts as we reached nearly 1000 accounts on our vote list before we were able to get out our initial full automation release at about the 8-month mark. When we did release full automation, we chose to keep all 10 accounts and scale our HP across them for the reasons detailed above.