Generally speaking, you don't want thousands of mostly-empty indices. A single shard can usually handle millions of documents (e.g. my macbook air can comfortably handle 15-20m docs in a shard without breaking a sweat). Each shard has a certain amount of overhead, so if you aren't using a shard fully you'll be losing a lot in wasted overhead.
Fewer indices + filtered aliases is probably a better route to take. Aliases have essentially zero impact on search performance. Under the covers, you can think of aliases as a simple map from alias -> index. So looking up the underlying index is very quick.
The place where aliases can get you in trouble is on the master. Aliases live in the cluster state, and the cluster state is managed by the master. If you have huuuge numbers of aliases, you can start to see the master bottleneck on processing cluster updates, and sometimes OOM in the worst offending clusters. The situation has steadily improved over time, so the level of problem depends on your ES version number.
Another side effect of giant cluster state is that the state is published to all nodes. So if your cluster state is 1gb, the master needs to broadcast that 1gb to all the nodes. This too has improved over time: old versions republished each cluster state, newer versions send deltas and batch stuff, etc. But it's still something to be aware of.
So...you don't really want hundreds of thousands of aliases either =)