Now you know why programming is not considered engineering. There are plenty of programmers who pride themselves in not caring about "theory" ("I didn't go to school and now I'm making money building cool stuff!!") and thus history is repeated.
Also, I don't feel the need to be called an engineer. I just write code, hoping that it would work most of the time, under as many diverse circumstances as possible and trying to meet the client's needs. It sounds trivial, there's no "theory" in it, but sometimes is hard as hell to do all these 3 things right.
The most successful of these are now invisible. Either because they are available libraries or so ingrained in the background of what we are doing.
See for example regular expressions, parsers, garbage collection, databases, file systems, CPUs.
For CRUD apps, "Out of the tarpit" (http://shaffner.us/cs/papers/tarpit.pdf) is an interesting paper that I hope describes how the mainstream programmer will build CRUD apps in perhaps ten years time. (I already used a variant of their techniques in a previous job, and it was rather pleasant.)
But yes, in practice knowledge of theory often acts more as a gatekeeper for getting into the likes of Google than you will use it. But when you do spot some opportunities to replace endless workarounds and tedious manual monkey-work with an elegant overarching principle, it often makes all the hours spent studying worth it.
As an great practical example: shake (http://shakebuild.com/) is a build-system that was born out of our frustrations with Gnu Make at Standard Chartered Bank.
Similarly, Bloomberg used to use C++ to describe financial derivative contracts. Those derivative contracts don't fit well into class hierarchies. Switching to an embedded DSL approach embedded in a functional language made the software easier to write and more robust to common errors especially when maintaining.
Of course we're all standing on the shoulders of giants. So does the milk-man, who goes door to door using a vehicle of which he doesn't know much about how it was built/what its underlying principles are (is it a Otto-based engine? or a Diesel one? does the milk-man need to know the laws of TD?), but that vehicle is paramount to the milk-man's financial success, so to speak.
All I'm saying is that we don't all need to be like Rudolph Diesel, Nikolaus Otto or James Clerk Maxwell, we can still do our jobs as programmers perfectly fine the same as a regular milk-man does, we don't need to know the theory behind CPUs, garbage collection and the like in order to write code that does stuff.
Don't get me wrong, I get what you're saying and understand your points, I just think that right at this moment the programming world needs more "milk-man-like programmers", because if we build walls around our profession ("you can only be a programmer if you know CS theory" and the like) then nothing good would come out of it. I mean, we will certainly build some cool, nice programs, but the world right now doesn't needs just some, few "cool, nice programs", the world needs lots and lots of code. In order to have lots and lots of code we need more programmers.
The world does not need lots and lots of code or programmers; the world needs less but better code and programmers, quality over quantity.
But this objective is thwarted when the idea keeps being thrown around that "everybody can, and should, code." There is already a glut of bad code developed by "programmers" unaware of what they do not know and unwilling to continue learning to improve.
Bad code, be it un-secure, un-performant, or un-usable code, is turning off consumers, and the earlier we sit up and seek way to improve code and product quality, the better.
Nah, we can also have our programmes write code for us.
Snark aside, we are somewhat in agreement. We just have different personal preferences: I am happy to spend lots of time studying mostly useless theory for fun, and the ability to rescue me from endless tedious and unreliable hacking/patching every once in a while.
You are probably happier to deal with the tedium, and occasional blowing up of your software at runtime (Python, I am looking at you!)---in exchange for not having to waste all your time on CS theory.
The difference between a milkman and a programmer is that a programmer can build her own little robots to do all the tedious task for her. (And in most cases, by `robots' I mean little software tools, and not so much any hardware.)
The milkman can come up with some ingenious things too, eg a better route, or perhaps a particularly clever way to `tetris' the bottles and crates in the car---but it's not a core part of his job.
In contrast to the sibling commenters, I am happy about every milkman-programmer there is. That means less competition for my own breed of skills.