99,9% of code written will not be specific to ARM, nor will it be CUDA code.
Most programmers will still be busy assembling software from prefabricated low-level parts (which may have ARM optimizations or run on CUDA). If (for example) you use Tensorflow, you will not need to deal with CUDA, even though Tensorflow runs on top of it.
GPU programming is not for the faint of heart, debugging is much more tedious and you need to "think" parallel. You can't be a clown programming GPUs like you can with Javascript. There aren't a lot of jobs to go around either, even though they may be well-paid.
Most of developers are not working with code that requires top-notch computer power; I don't think that Nvidia/Intel rivalry will affect the market for people who know JS, CSS and HTML to a significant degree.
But generally speaking, learning Caffe, Tensorflow and math in general sounds like a much more important investment than low-level libraries for specific hardware.
I think this is a good point. One other thing I would like to emphasize, after having worked only a little while professionally, is that its not as important what specific architecture you choose while learning, except that maybe you will write code faster and already know many of the nuances. There are so many resources available to learn any architecture now, that the best advice would be to pick a reasonable one and just learn it; with that experience, one can then move with confidence between architectures.
Knowing the architecture of ARM is a perk, but the software is going to be all CUDA / OpenCL / Vulkan Compute - the CPU side is just going to be a shim layer to get kernels to execute on that graphics card and won't take much development and will hopefully just be the same open standard everyone uses.
I agree with you, except when they aren't hidden...
For some large percentage of the problems we fix I agree with you, but every once in a while you need to peel back a layer or two of abstraction and ask "Why did it do that?" Most abstractions leak, despite whatever heavy lifting they do for us.
Having familiarity with those underlying implementations can make that trouble-shooting much easier. So I guess it is up to each developer to understand how likely they are to peel back different abstractions. I suspect a JS dev will rarely want to look at the assembly and C/C++ might want to every week.
