As many already noticed, the rise of Python is not counter-intuitive at all. (I'm a scientist myself).
Basically modern python offers you a spectrum from easy to understand and quick to write python programs (those will be slow), to purely glue code that connects a lot of high performance c/C++/fortran code.
And many scientists will start from pure python code with the help of numpy. In many cases it will be good enough. But if needed you can always interface with other libraries, or write yourself high performance c/c++/fortran code for the most performance critical bit, and use python to glue it together. That flexibility where you can trade speed of writing the code with the speed of execution is very valuable.
At this point we can say that against the two criteria of a spectrum from prototyping to heavy lifting and ease of embedding external high-performance libraries, Julia is simply better than Python. Julia does have two drawbacks of being tied to the one, rather heavy metal, implementation and lacking the wealth of libraries outside scientific computing.
From just my personal experience, I've had a python code interfaced with C that I rewrote just for fun in pure julia. It was significantly slower then the C code and I couldn't as easily use OPENMP parallelization (although the symbolic derivatives are great). Obviously I know julia much less well, but so far in a few cases I tried, I could not convince myself that julia offers me enough advantages over my current approaches that rely on python & C/C++
As I guess you're hinting at, writing performant pure Julia is a quite different kettle of fish to writing performant C: it's not surprising that a first attempt isn't a rousing success. But there's a spectrum of rewriting possibilities: you can write Julia-interfaced-with-C as a direct analog of the existing code, and you can convert just those parts of the C code that you think would most benefit from Julia's JIT into Julia, leaving most of the heavy lifting in C.
This is changing BTW. There's been lots of improvements in escape analysis and hoisting allocations out of loops in the upcoming v1.9 that will start to make "bad codes" a lot less bad. In fact, it's already starting to impact how to write tutorials on what is a bad code haha.
True, although the Python-Julia interop is surprisingly good. Gradual migration of legacy code from Python to Julia might be a possibility for some of these groups. But I was really thinking about the situation for new projects when writing that comment.
Same thing, you will want to reuse existing code, and you do not want to split knowledge in your student group. There is no such thing as 'gradual' migration: I either have to support Python in my group, or Python and Julia -- until everything is migrated.
If I have a working ecosystem using Python, with students trained in Python, and all previous work in Python, there's a whole lot of opportunity cost associated with me deciding to have the next student use Julia. I'd rather have that student build on existing tools and knowledge and do something new with their time.
Basically modern python offers you a spectrum from easy to understand and quick to write python programs (those will be slow), to purely glue code that connects a lot of high performance c/C++/fortran code. And many scientists will start from pure python code with the help of numpy. In many cases it will be good enough. But if needed you can always interface with other libraries, or write yourself high performance c/c++/fortran code for the most performance critical bit, and use python to glue it together. That flexibility where you can trade speed of writing the code with the speed of execution is very valuable.