Here are a couple of things to consider:

1) Backup. As much fun as it will be to have that many databases, there will be an equal multiplier of database and log backups. Also, the backup job that has to issue thousands of backup commands will run longer than backing up the same amount of data in a single database. And you'll need to come up with some sort of restart strategy if the backup job dies in the middle.

2) Restore. But if you have the occasional need to restore a single subscribers data, it will be a whole lot easier with just a small database. If all of the data was lumped together, you'd have to restore somewhere else, and more over only the required data.

3) Look at storage replication instead of SQL Server backups, and see if they will mitigate 1 & 2.

4) Privacy. If there is any possibility of one anybody looking at data that is not their own, the separate database option looks better. This could be solved by having a separate schema for each subscriber, which may by slightly, bit not much more than that, less of a headache than all of those databases.

4) Clustering has no effect on the one vs. many database issue.

5) You will probably need to develop some sort of framework to manage all of the db's or schema's. Once you have that in place, it should also be possible to use multiple instances to keep the number of databases per instance manageable. It should also help manage the security issue in 4 above.