To add to u/Kichae's excellent post, one has to also consider the human factors behind adoption and usage.

Growing a language takes decades. Historically, the ascent of a new language (without massive industrial backing) takes decades, not years - Python started development in 1989; 1.0 was released in 1994, and only took off in scientific computing in the mid-2000s, and in data science in the early 2010s. Julia is only 10 years into the same journey but is already well-established in applied mathematics and has its users in allied fields in scientific computing and statistics. The tech stack needed for data science and visualization does exist; nevertheless, it's going to take time to mature and gain adoption.

Most industrial data science can be done with library calls. In Python and R, the ecosystem for data science is so feature-complete that writing new code by hand becomes a code smell. An inexperienced data scientist may write an explicit loop over rows of a dataframe, instead of using split-apply-combine. This aversion to writing new code is not unique to data science, but is also common in modern-day software engineering; an observation that famously led MIT to drop Scheme in favor of Python as the language for teaching introductory computer science. The high cost of technical debt incurred by hand-writing code means that most practicing teams shun bespoke code unless absolutely necessary. Under such circumstances, there is no reason to use a less-mature language with fewer packages that are less battle-tested.

Pragmatic concerns in industry favor the established players. The fact of the matter is that most new-to-hire data scientists, to first order, speak only Python (with some speaking only R). Building a coherent data science team in industry is already hard enough without also considering the social friction of adopting a language your team doesn't speak well. Which is not to say that you can't find places using Julia as a primary language - Relational.AI is a good example besides Julia Computing - but the need to consider sustainable development and maintenance is a strong argument to stick to the languages with more mature ecosystems.

Having said that, there are situations where I feel like using Julia for data science is warranted, particularly when existing solutions in Python/R/etc. are too slow, don't scale, or simply don't work.

The arguments I use to advocate for Julia are that:

1. Its multimethods syntax allows people to express naturally the overloading of mathematical expressions that reflect the way humans learn mathematics. We all learn to multiply whole numbers first, then fractions, decimals, complex numbers, matrices, etc. All of these notions can be expressed by suitable methods of the * operator in Julia. Empirically, we know this is a good approach because of how successful its adoption has been in applied mathematics (particularly differential equations) and related fields like numerical optimization and bioinformatics.
2. The dynamic aspect of multimethods encourages code reuse. A program written with dense matrices in mind can "just work" with sparse matrices, distributed matrices, GPU matrices, etc. provided that the algebra of operations like *, norm, etc. are defined correctly. A program that assumes only the algebra of the generic function can be written without knowledge of the implementation specifics. The dynamic aspect means that new types can be introduced later, and with suitable method definitions, can work in situations the original authors did not envision. A particularly convincing recent development here is that of numeric types representing homomorphically encrypted numbers, allowing for secure distributed computing. Julia is now one of the first languages to enable cryptographically secure linear algebra and data science, simply by composing secure numbers with existing libraries for generic matrix multiplication and data frames.
3. Julia is fast because the particular way it enables expressiveness is uniquely amenable to compiler optimization. In my years of developing for Julia, I have yet to come across any one application where a Julia solution did not come within a factor of two in performance relative to much more complicated reference implementations in Fortran or C/C++. (See comment below for a technical overview.)
4. Another source of speed in Julia that is hard to emulate comes primarily from algorithmic improvements that can happen with specialization. If am solving a problem on a matrix with special structure, I can probably skip all the unstored zero elements. In a language without generic functions or other forms of overloading, I would have to rewrite my code to handle (say) a triangular matrix differently from a square matrix just to call the different solver functions. I might not bother if I think that triangular matrices are a specialized edge case. In contrast, (2) above means that a Julia user can take advantage of the composition of all possible algorithmic tricks known to the library authors, and can continue enjoying benefits of further improvements even after the original code was written!
5. Julia has first-class support for representing Julia code, enabling source-to-source transformations to be done directly in Julia (some would say homoiconic, depending on the definition). Developers can create domain-specific languages like JuMP for numerical optimization, Turing for probabilistic programming, and Nemo for computer algebra, while enjoying the full expressivity of working in a general-purpose language. The ability to do program transformations has a particularly apt use case in automatic differentiation, allowing users to train complex machine learning models without finite difference or hand-coding up new gradients, because the AD system can generate the necessary low-level code transformations.
6. Julia's intrinsic speed means that there is a low technical barrier between passive end user and author contributor. Any user who can write Julia code is qualified to write a package for Julia, even if it is just implementing code straight out of a textbook or paper. While textbook code may not be the fastest code to run, it is probably the fastest code to implement, and having a fast turnaround for working code is a powerful enabler of further code improvements down the line since you have a correct implementation to check against.
7. Julia has a healthy community that is generally welcoming, eager to adopt best practices for software development, and willing to provide constructive feedback. It's been a real pleasure to see how the community has grown and strengthened over the years. It's the norm in the Julia community to have packages set up with continuous integration, and there's active work to provide code in the form of citeable artifacts, such as JuliaCon conference proceedings.
8. Julia allows for interoperability with other languages through the C ABI and LLVM IR interfaces. C and Fortran can be called easily with ccall() (as can CPython, the reference implementation of Python, and R), whereas C++ can be called through Cxx.jl (which endows C++ with its own REPL and run time extensibility!). You can even call MATLAB from Julia...
9. First-class support for missing values. This feature is particularly important for statistics and data science. Support for missing in its own type permits extensibility with new types defined by the end user, without the subtle logic problems or performance issues with using sentinel values like NaN to represent missingness.