I am assuming cluster rebalance is not blocked and node3 disk does not have anything other than ES data. The later is important as available disk space matters not the size of the disk. You can verify this using node stats API
Unless you are experiencing performance issue I won't worry about it. In my experience, unless you hit disk high watermark or certain node is overloaded ES doesn't move shards. Because moving a shard is an expensive operation, consumes network bandwidth, incurs gc and loses caches. When I new shard is allocated it takes available disk space into account. But ES cannot predict how big this shard going to grow in size. It treats all shards equally. Some shards may grow faster but won't be moved unless you hit watermark.
If you are experiencing performance issue, you need to first decide which shard to move. This depends on your query volume on each index and shard size. You can use then use cluster route api to move specific shard(s).
For a long term solution, I would explore something on the lines of ILM since you are using time based shards. Your cluster size is small. So you need to assess based on query volume on the old data.
Finally for some reason you want all nodes to have roughly equal utilization, compute (total data size on all nodes * 100) / (5 * disk size). The set low and high watermarks slightly higher than that. This will force ES to rebalance. Once rebalancing completes you can set those back to default. Make sure you create hourly indices for several hours and may be even daily for a day or two before changing watermark. I won't recommend this as I don't see major benefits but it can go wrong badly if not done correctly. Including option only for information.