as most candidates could code or design or work to specifications
I call bs or they have a very low bar to meet "to specifications". Code that works to spec is great when it works and horrible when it doesn't work. Most people design systems that cannot be easily debugged or fail in unexpected ways. But yes, they work great when they work. It's shipped, no longer my problem, right?
Do we expect kids in schools to actually WANT to learn all this? What kind of madness do you need, to want to learn about all these things?
While I don't have first hand experience, I have a lot of theory and abstract knowledge. Nearly every new-fangled thing that's out there is just a minor flavor of what has been solved back in the 1970s. Even though I do not have any real world practice in many of these things, I have had highly regarded consultants come in and I've corrected them on design entirely from theory. Of course I learn a lot more from them, but having a strong foundation in theory and understanding the problem domain is very important.
My posted child for applying my theory was when I helped debug a "threading" issue in a program someone wrote in go. I was given a high level explanation of what the application was attempting to do, and how it was attempting to do it. The problem that was occuring only happened with GCC-go. Coupled with my Wikipedia knowledge of how go works internally and a quick google on GCC-go, I was able to figure out the issue in about 5 minutes and gave a recommended alternative which worked.
Armed with nothing but theory, I was able to figure out a thread scaling issue in a language that I knew virtually nothing about, that used a custom threading model, and the issue was specific to the compiler it was using. The issue turned out to be how GCC-go scheduled threads and handled blocking, which go should technically not have any blocking.
Old programmers never die, they just hit account block limit.