I wonder if the parallel stream API with a virtual thread pool would make it better or worse.
Since this is amortized exponential growth it's likely making negligible difference, although it is good style to tell data structures what you know about their size early.
The Go approach doesn't appear to pay this penalty, it's just incrementing a (presumably atomic?) counter, although I have no idea where these tasks actually "live" until they decrement the counter again - but most of the others are likewise using a growable array.
In the unmanaged languages, those intermediate buffers should be freed immediately during the re-size operation.
But in the managed languages, they might stick around until the next GC. So the peak memory would be higher.
In this example the runtime overhead is going to represent more of the memory usage anyway but it quickly isn't negligible. E.g. a list of size 1M is going to be ~8MB (64 bit addresses). So even if the array is re-sized from 1->2->4->8->...->~500K, the end result is not going to be worse than 2X the size.