@val - thanks for the feedback, on an interesting question that gets a fair bit of internal discussion.
Historically Cloud provided a "one size fits all" type approach for reasons of simplicity, and our empirical findings back then suggested that for most cases maxing out heap size was preferable.
Our recent move to template-based deployments does open the door to alternative node sizing, though it's not something we're actively looking at currently - we're always open to feedback on this! Out of interest, do you have any benchmarking you use to decide between (eg) 1x30GB vs 4x 8GB?
The two specific considerations you mentioned, CPU and network bandwidth, aren't believed to be issues in practice - eg regardless of node size, each ES process runs on a large multi-tenant server with resources carved out using cgroups, and ES scales the thread pool sizing automatically.
(In our "on-prem" version of Cloud, customers are more flexible with node sizing, though - again empirically - this seems be related to logistics or internal billing considerations rather than performance)
Alex