I think these sort of questions crop up in large part because of the narrative that Julia is the one language to replace them all, but it’s important to remember that the “two language problem” exists in the context of scientific computing, or more broadly wherever both high performance and expressive syntax is valuable. The problem doesn’t exist in many other contexts, like systems programming.
As mentioned earlier in the thread, Julia has intentional design features that are at odds with the priorities of systems programming languages. I haven’t done it, just read a bit about it, but systems programming is close to the machine, has a machine-dependent layer at the least, and much more limited than application programming; for example, you can write OS kernels in C, but you can’t use the C standard library. By contrast, Julia is abstracted from the machine by several layers, portable, interactive, and is higher level than C in many other ways. Could you write Julia code and claim it’s an OS kernel? Yes. Could it be compiled to something that actually works? Not now. Assuming systems-Julia was designed, would it make coding easier and safer than using systems-C? Probably not.
There is actually some demand for stripping down Julia for some contexts. GPU programming is already in use. There’s related work on StaticCompiler; a Julia session has a large memory footprint, and people are interested in smaller executables that can run on more limited machines or integrate into other languages with little overhead. Although I doubt manual memory management will ever happen, the work on the compiler’s effect analysis could allow soft realtime applications to use a lot more mutables without needing the collector interrupting. I mention these because they seem to edge Julia in the direction you’re thinking of, but it’s still a far cry from systems programming.