What really matters is, that you at all costs keep the physical shard_size <= size of process memory and that the process memory are pinned to the ES Java process, so no swapping has to be carried out.
And make sure, that you only utilize 50% of your physical memory for the ES process. The rest should be accessible to the OS layer for Lucene to use via the OS.
Apart from this, you can query across several indices without any problems.
I'm stating, that you easily can write much more to single node, but when you want to read it - you will run into troubles if you need to read multiple full shards into memory.
If you known what you are looking for and know your data, then it's usually not a problem, but it will be if you provide access to Kibana to a large group of data scientist. If you can manage to have pre-configured dashboards, then you are also safe.
Elasticsearch can be tuned in a number of ways for different use cases, and determining the ideal shard size and number of shards a node can handle is no different. Having a small enough data set per node so that all data can be cached by the OS (which it seems you are recommending if I read your post correctly) may be applicable for search use cases with very high query rates and low required latencies, but this does in my opinion rarely make sense for the vast majority of logging use cases.