I agree with this.
There are some situations where you need to keep a long-running process which is only used occasionally. As @dom mentions, a good example would be channel processes (which, from what I can tell, are now being hibernated by default). Another example I can think of are mediator processes which are used to serialize data flows (internal queues, gen stages, and such).
More generally, any occasionally used process which shouldn’t be dropped (e.g. because there’s a client on the other side who might interpret this as a netsplit) or which is costly to reinitialize, is a potential candidate for hibernation.
The reason why you might need hibernation lies in the fact that an idle process (AFAIK) won’t be GC-ed. So if a process accumulates a lot of garbage during the period of bursts, but then becomes idle for a longer amount of time, you may end up with a lot of needless memory allocated.
This can be particularly dangerous when combined with refc (aka large) binaries. If a large binary is passed through a process which will be idle for a long time, the binary might never be reclaimed. Ultimately, you might end up consuming the entire memory, and the system might be brutally killed. For this reason, I sometimes preemptively use hibernation in mediator processes, especially if I estimate that they will be long-living and occasionally used. I figure that I’d rather sacrifice some processing time to get predictable memory usage.
Of course, there are other techniques to control memory, such as spawning a one-off process where most of allocations are performed. But if you need to do these allocations in a long-running process, or if such process is propagating the data around, then hibernation can be a useful tool to keep the memory usage stable.
