There's also issues with wanting to use the old Fortran code in new projects and if the new alternatives don't have a good interface for Fortran, it's a bit of a pain to integrate.
C++ really crippled itself in this regard by never making a standard. I never bought Stroustrup's claims of "but you can write your own" for these reasons.
Granted, there's plenty of fast libraries written in C/Fortran that don't have a Julia equivalent yet, and depending on the overhead of ccall(), you may wish to stick with writing the rest of your code in the language of the library.
My other problem is code generation. I can't generate Julia code yet.
Perhaps I am misunderstanding your meaning here, but Julia has a range of metaprogramming functionality including both Lisp-like macros, as well as "generated functions" that allow custom code specialization based on input type signatures (https://medium.com/@acidflask/smoothing-data-with-julia-s-ge...). These capabilities have been used for DSLs (e.g. https://github.com/JuliaOpt/JuMP.jl) and parser generation (e.g. https://github.com/abeschneider/PEGParser.jl).
Just because they're good alternatives doesn't mean they merit rewriting software that cost millions upon millions to write the first time.
Plus when you're talking about code that runs on 5000 machines, even just a 5% difference is meaningful.
That said, I believe most of the post-MPI HPC frameworks are based on C/C++ with little support for FORTRAN.