I did not write much SIMD code for myself, but as far as my understanding goes, using SIMD intrinsics is essentially assembler programming. And your whole question could be rephrased just by replacing "SIMD" by the word "assembler":
the code takes 10x to 100x to develop than "high level code"
it is tied to a specific architecture
the code is never "clean" nor easy to refactor
you need experts for writing and maintaining it
debugging and maintaining is hard, evolving really hard
...
So I think the "industry consensus" about SIMD is pretty much the same as the "industry consensus" about assembler:
don't write it if you don't have to - use a high level language whereever possible and let compilers do the hard work
if the compilers are not sufficient, at least encapsulate the "low level" parts in some libraries, but avoid to spread the code all over your program
since it is almost impossible to write "self-documenting" assembler or SIMD code, try balance this by lots of documentation.
Of course, there is indeed a difference to the situation with "classic" assembler or machine code: today, modern compilers typically produce high quality machine code from a high level language, which is often better optimized than assembler code written manually. For the SIMD architectures which are popular today, the quality of the available compilers is AFAIK far from that - and maybe it will never reach that, since automatic vectorization is hard. See, for example, this article which describes the differences in opimization between a compiler and a human.