I"ll go on and make another bold claim. Focusing on lower level stuff and systems concepts lay an excellent foundation for designing complex systems regardless of the language used. Once you understand how a program is executed from the ground up i.e. right from the program counter to page table lookups to cache hits to cache coherency, all abstractions are easier to deconstruct and understand. I work up and down the stack and this has been my, quite possibly just anecdotal, experience.
The funny thing is, its the opposite for the low level stuff. Nobody does it, so there's a huge demand, which results in too much work for those who are filling those roles.
Game development is broken for a litany of reasons, but I resist the urge to go into it to keep things on topic. I will say that it gets kids in STEM, and for the youngin's, getting into the low level stuff is a safe bet for a profitable career.
This was not my experience or the experience of people I know at all.
I imagine that it depends on which companies you work with, or what country you're in, but my experience was that low level skills often didn't give you very much in the way of extra job security, and certainly didn't save you from crunch, low pay (much lower than everywhere else in software), etc.
Still, I have to say that there is indeed an opportunity for a few low level people there.
How much does an engineer making $200k a year have to reduce X by before he pays for himself? Not much, and simply finding a hotspot and doubling the performance by aligning a data structure or whatnot could pay for his salary for a decade.
The old adage that computers are cheap and engineers are expensive is about 15 years out of date for a large portion of the software being written today. That is when companies stopped being able to generally externalize the costs of shitty code. Plus, as microcontrollers ate the world, the ability to ship a $1 micro controller instead of a $10 one on a product run of 100k units can mean the difference between a competitive growing company and a dying one.
As a real world example, if an operation involves a network call and you see the RTT dominating the time. You may want to think of ways to avoid the call (caching etc..) if possible to get really good gains.
But I'm an EE, so maybe I misunderstood some finer points?
Amdahl:
A fairly obvious conclusion which can be drawn at this
point is that the effort expended on achieving high
parallel processing rates is wasted unless it is
accompanied by achievements in sequential processing
rates of very nearly the same magnitude.
A point made when we read the paper was that Seymour Cray always made sure that his computers were also the fastest scalar computers even though they were sold as vector processors.
I think mathematicians consider an upper limit a positive bound - positive, in the sense of being well defined; you're using negative in the other sense? I actually like that quite a bit.
When you know what the stack and the heap are, when you know how memory locality affects performance, when you know the full cost of allocations, you can write better Java/C#/OCaml/Haskell, you can check on the assembler they output, you will be ready to occasionally write small C libraries if portions or slow, etc.
Ignoring this stuff completely leads to text editors made in electron.
However I do agree with you, getting into web dev is easy. Doing things closer to metal is harder. I would definitely love to do more low level C programming.
The more a company spends on infrastructure, the more they need low-level people. A good low-level programmer can reduce cost requirements 10x or more. Any company spending millions or billions on infrastructure can make enormous savings by hiring the right people. Crucial for Google, Amazon, Facebook, and even midsize startups can see a big improvement.
And its difficult to fill those jobs. Which means, there's opportunity there.