Maybe relevant discussion.
There are the newer RNGs, like PCG and xoroshiro, that look strictly superior to mersenne twiser, but I am not an expert on that. If one has hardware support (for aes), then there are very fast cryptographic RNGs as well. Unfortunately, some architectures lack the hardware acceleration (ancient x86, some arm, maybe some atom). Vagaries of the cross-compilation build process might force generic binaries to use slow software implementations. But all modern CPU where you would realistically like to run non-trivial computations have hardware acceleration.
A fork-on-task model of RNG states would incur an overhead on every single task creation. Hence, this can be done at most for the default RNG, and only when using an RNG with fast seeding and small state, i.e. not mersenne twister (can work for PCG, xoroshiro, etc, and most cryptographic RNG).
It is arguable whether the price of default CSPRNG is worth the gain of mitigating some security flaws. Main price would be small slow-down of
rand-heavy code that uses the default RNG on sane CPUs, and big slow-down on a few specific CPUs. Main gain would be to mitigate an entire class of security bugs (secondary gain is that reasoning about randomness becomes easier).
Speed is the more common concern, but security incidents have way bigger impact than a handful of wasted cycles. Really good code would be unaffected either way (if optimized for speed and random generation is a bottleneck, then the code should already use a faster RNG than mersenne twister; if security is relevant, then the code should already use a CSPRNG).
I personally think that adopting a fast CSPRNG as default, and exporting an even faster non-cryptographic RNG is a no-brainer. Most security people would agree, and some other modern languages agree as well, e.g. swift. But reasonable people can disagree on this point; and the julia user-base is more “technical computing” than swift “general purpose”, so the decision is much harder for us than for swift.