Why 30G though? Isn't it enough to be of the size of shared_memory.bin? In that case setting both the size of shm and ram-disk to 22G should still have decent margin (4-5G).

/run that I use in my way of setting things up is a system-wide place to store various run-time data, so I can't use all of it. I use higher values because I keep same setup scripts for other nodes, and for my fully featured account history node it's already:
du -csh /run/hive/shared_memory.bin:

22G /run/hive/shared_memory.bin

But that doesn't matter much, the configured size limit doesn't pre-allocate RAM. It simply sets an upper boundary on how much space can be used.

12 hours is only a bit less than syncing from scratch through p2p, so downloading in that case is not a viable solution 😁

I'm not that sure if it's just a bit less, one of my recent sync tests (6 weeks ago) took me 42 hours. I'm afraid that you might be too optimistic about sync speed in real life conditions.

So, I guess the version supporting split block log is the next one, right?

Yes! :-) I can't wait for that. Unfortunately being a most used block_log provider I have to wait for global adoption. Or do I? :-) Once it's officially released I will switch :-D