It appears from that graph that the node in question bottoms out around 5GB, and that, indeed, the periodicity of GC is quite long. How aggressively I would pursue reducing the allocated heap would depend on how the current usage compares to planned capacity, in terms of volume of retained data, indexing load, search load, number of indices.
If you believe that you are currently at about the expected usage in those terms for a reasonable time horizon (perhaps 3 - 6 months), then you could easily cut that node to, say, 15GB, and continue to monitor for the possibility to cut back more. You could conceivably go as low as 10GB.
If, on the other hand, this is a relatively new cluster and usage is expected to grow substantially in the near future, I would consider waiting until usage is more mature before adjusting - unless you are experiencing latency spikes during GC, in which case, of course, it should be a higher priority.