I've long wondered why the upvote services don't create a one-off post themselves, generate 10 comments there every day and upvote them by 100%.

Me, too. It would improve the spam problem, and it would offer an avenue for passive rewards - making their product more attractive to potential clients. And I have also wondered why their clients don't demand it.

The number of new posts and the number of visitors are important indicators of the value of a domain, so I could imagine that this is the reason why the mechanisms were set up in this way.

I agree, here, too. At one time, there were two payout windows - one after 1 day and one after 30 days. When they switched to 7 days, they said that there was almost no significant voting after 1 day. IMO, this is because they're buried from people's feeds after that. If we want posts to have longer lifetimes, I think that some sort of recommender is needed (In a way, Thoth is a first pass at creating a decentralized recommender).

So I assume that this option still exists today and is just not offered by the Steemit frontend.

It's definitely still possible. This is how eversteem rewards posts after payout. I'd love to see @the-gorilla give us a beneficiary option in replies through condenser. Something new might be to let the commenter set a default beneficiary amount that gets assigned dynamically in each reply to whatever account created the post that the commenter is replying to. Maybe that would create a more collaborative and engaged environment(?).

I have thought about making use of comment beneficiaries so that Thoth can have more beneficiary slots (for delegators), and so that voters can direct rewards to a single historical post/author, instead of splitting them among all authors in the top-level post. It's a tradeoff between not wanting to create spam comments vs. customizing the results and including more delegators. Not sure if I'll set that up or not. The ideal thing might be to create the capability, and then let each Thoth operator experiment to see whether it makes sense to use the capability on or not.

Finally, why do you send 70% to @null on @thoth.test posts because it's just a test?

3 reasons:

1. Yes, mainly because it's still just testing;
2. I don't want to set expectations too high for authors and then have to take it away when I add delegators, so that's a buffer that I intend to draw down later, without impacting other stakeholders (the amounts can be adjusted in the config file, so no Thoth operator would be compelled to burn anything);
3. I think automated tools like this should burn some percentage, just as a sort of signal that the operator has the interests of the ecosystem in mind. Even when it goes fully live, I think I'll probably still burn some amount.