I don't see how it's "very hard" in the general case. Compilers have been increasingly cutting programmers out of the loop for 30 years now.
It's the reason we program apps and even games in C++ and not in hand-rolled assembly as we did in the 80s, and why we can use crazily high level languages like JS and still get within an order of magnitude of C with a modern JIT.
However, I don't think it is useful to consider a compiler to be a replacement for programmers. Compilers are tools for programmers. The more time a compiler saves a programmer, the better it is.
I think there is a middle ground between writing inline assembly and fully automatic vectorization that would be less time intensive than manual vectorization and more predictable and available earlier than fully automatic vectorization. I wonder what would have to be done to find it and provide support for it in GCC/LLVM.
You also need to take into account that a huge chunk of the work in SIMD is the need to rearrange your data to be more amenable to the CPU. C++ compilers are very restricted in what they can do for you there.
The point is simply that C doesn't have the concepts you want to program with. Vectorization only gets you so far, there are many other things you can do with AVX/SSE. It doesn't need to be ASM, it could be supersets of C instead (like CUDA).
Intrinsic functions for AVX is what I use and I don't see the problem with using those. It sort of is such a superset of C.
In practice a few numerical computations (BLAS, FFTs, etc) are reused a lot by many. It is worth it to write those few libraries in assembly (or at least intrinsics).
For the rest we just have to live with a small performance penalty.
I am just saying "if you want to go the extra mile to get high performance, you can beat compilers". In most scenarios of course it makes most sense to not bother.