[DOCS] Note assumptions for shard size and count recommendations (#76353)

On the "Size your shards" page, the shard size recommendation assumes a time
series use case. Similarly, users shouldn't count nearly empty and rarely used
Enterprise Search system indices against the recommended shard count limit.

Closes #76328.

docs/reference/how-to/size-your-shards.asciidoc

@@ -128,8 +128,10 @@ Large shards may make a cluster less likely to recover from failure. When a node
 fails, {es} rebalances the node's shards across the data tier's remaining nodes.
 Large shards can be harder to move across a network and may tax node resources.
 
-While not a hard limit, shards between 10GB and 50GB tend to work well. You may
-be able to use larger shards depending on your network and use case.
+While not a hard limit, shards between 10GB and 50GB tend to work well for logs
+and time series data. You may be able to use larger shards depending on
+your network and use case. Smaller shards may be appropriate for
+{enterprise-search-ref}/index.html[Enterprise Search] and similar use cases.
 
 If you use {ilm-init}, set the <<ilm-rollover,rollover action>>'s
 `max_primary_shard_size` threshold to `50gb` to avoid shards larger than 50GB.
@@ -165,6 +167,10 @@ have at most 600 shards. The further below this limit you can keep your nodes,
 the better. If you find your nodes exceeding more than 20 shards per GB,
 consider adding another node.
 
+Some system indices for {enterprise-search-ref}/index.html[Enterprise Search]
+are nearly empty and rarely used. Due to their low overhead, you shouldn't count
+shards for these indices toward a node's shard limit.
+
 To check the current size of each node's heap, use the <<cat-nodes,cat nodes
 API>>.