In academia code is the means to an end, which is usually a paper. This means that the experience of writing the code, making sure it's portable, readable, etc. don't really matter. These are all industry concerns; specifics of implementation, not algorithm design/mathematical questions.
This isn't reflected in Julia as a language as much as it is in Julia as an ecosystem. Some of the packages I work with are poorly maintained or designed with 0 thought to the issues I described earlier. And since Julia is so new, there are few alternatives.
Imagine if your software was written by your college professor who'd pushed to prod maybe like 3 times in their life. Instead of just fixing the damn bug they're liable to make you fix it instead as an 'exercise for the reader', or posit that the problem input is outside of the scope of their class and refer you to another one.
My example of this is the Colors.jl package. Images, rather than being 3D arrays of floats/ints, instead become 2D arrays of RGB/HSV. But you can't do any arithmetic on RGB/HSV values, you need ColorVectorSpace.jl for that. I'm sure it makes sense, but I can't help but feel as if sense is taking precedence over the programmer's experience in many of these packages.
Again, I don't think Julia as a language is unfit for widespread use. But before it can be, it needs to burst out of its ivory bubble.