Let's say it a different way... For each index, you would have not more than one shard per node. However multiple indexes can use each node.
For example, if your index is configured for 2 shards and 1 replica (typical of a time-based use-cases like logs) you would have a total of four shards, two primary and a replica of each. According to the rule you would want four nodes. Shards would be written like this...
Node 1 | Node 2 | Node 3 | Node 4
------ | ------ | ------ | ------
Mon P1 | Mon P2 | Mon R1 | Mon R2
Tue P1 | Tue P2 | Tue R1 | Tue R2
Wed P1 | Wed P2 | Wed R1 | Wed R2
This is simplified a bit as Elasticsearch won't put all primaries on the same nodes, but the main point is there are multiple indexes using each node, but only a single shard per node for each index.
I am not so sure that I agree with David, that matching shards to cores is a good rule of thumb. In my experience (which I am sure is less than David's so I am open to him correcting me) you will be limited by Disk IO long before you are limited by CPU. The main reason to spread shards across multiple servers is to spread the disk IO load across those servers. Similarly, the main reason to feed your servers lots of RAM is to hold as much of the working set in cache as possible further avoiding Disk IO. The one shard per index per node rule is basically saying that you want to be able to run your queries as parallel as possible in order to spread the Disk IO load as much as possible maximizing throughput.
Hopefully that helps.
Rob