As to not being able to beat MKL, it isn't even necessarily hands down the best BLAS around. For example, OpenBLAS [3] is about as good as MKL, depending on what you're doing. They each have their strengths and weaknesses:
1. OpenBLAS is faster than MKL in all the level-1 tests for small numbers of threads (1-4). The difference is larger for smaller problems. In small level-2 and level-3 instances, however, MKL does better. Specifically in the case of matrix-vector products, MKL seems to do much better.
2. On various linear algebra tests with LAPACK, MKL is faster for smaller problem sizes, whereas OpenBLAS is faster for larger problems.
3. In general, MKL seems to have better tuning for threads. OpenBLAS, on the other hand, has optimized kernels for LU and Cholesky factorizations, which is what GotoBLAS [4] – on which OpenBLAS is based – did too.
Blake Johnson, who is a regular Julia contributor, did an excellent analysis of this, complete with pretty Gadfly-generated graphs, which can be found in the discussion of this issue: https://github.com/JuliaLang/julia/issues/3965. Interestingly, I believe that Kazushige Goto, who originally created GotoBLAS, now works on MKL at Intel.
All of the "modern" numerical computing environments can use whatever BLAS and FFT (and ...) libraries are available on the host system, including MKL. What new languages offer isn't (usually) better execution speed (though there's still plenty that can be done with optimizing evaluation of linear algebra expressions at a high level), it's faster and more pleasant development of numerical codes.
Oh, sure they say, "well, we don't know the other architecture, so we can't optimise for it," but you know this is full of lies, as if AMD were some obscure architecture that Intel can't possibly know if it supports SSE or not.