I'd be interested to know what line of work you do, programming wise. My experience tells me that a lot of programming that is being done is meant to be powerful and meant to be built quickly. Running quickly and with low tolerance for faults is a little less important because very few things are mission critical. While anathema to the academic, it demands a certain skill set, which is the ability to very quickly assimilate new arbitrary knowledge about libraries, software, and code, that the programmer hasn't seen before. The result is a fragile sort of knowledge that often lacks formality and granularity but is sufficient enough to accomplish a task very quickly.
There is definitely some truth to what you say. I started out as a programmer in 2007 but quit programming and went into infrastructure/systems engineering after my first programming job precisely because of what you just described. I got into computers and programming initially because I had a desire to cultivate a deep understanding of the computer and how it worked, and I discovered very quickly that modern programming is all about the latest "shiny new framework" and slapping something together as quickly as you can (the politically correct term for this is, of course, agile). That's all well and good, and there is a definite place for that because speed to market is very important in a competitive environment. And a lot of people really seem to enjoy that style of rapid development at the expense of truly understanding what is going on. But it wasn't for me.
That said, there is also truth to what the grandparent said when he posted this:
I wasn't saying a programmer should write everything from scratch every day. But if you don't know how to, you're SOL and at everybody else's mercy when something goes wrong. You're costing your company money. Because things inevitably go wrong.
Those people with the "fragile sort of knowledge" are at everyone's mercy when things go wrong. They literally have no clue where to go next or how to troubleshoot if things don't work exactly right. And in my company, it's me and others at the heart of the infrastructure devops teams who they come to when things go down, because we are the ones who actually understand how it all really works underneath the high level frameworks and scaffolding. We understand the networking, the HTTP, the authentication protocols, languages and everything else at the bottom. The best programmers, at least at this company, are the ones who did those rapid development jobs for just a few years and moved as quickly as they could into backend "Developer Center of Excellence" type teams, where their job is to support other developers, create standards, write programs designed for the infrastructure as a whole and therefore learn the deeper points of the technologies.
Conclusion: The grandparent is right when he says that the best programmers understand how things work under the hood and could write these objects from scratch if they had to. But you are right when you say that not all programmers have to be at that level in order to do something effective. Both types are essential to organization, because you have to have people fast enough to outmaneuver the competition, but also really solid people in reserve to back up the quick and dirty developers when things go wrong.