In order to discuss categories at all, you have to place some limit on how far to stretch the equivalence of different things. Sure, a physical thing is transformable to a logical thing, but doesn't that affect our categories? We're pretty bad at finding or agreeing on the lines between the categories we create, so I don't worry about that much.
I didn't say that programming is never anything like engineering. I apply engineering-inspired approaches to my work all the time. But here's another perhaps eccentric opinion: when I'm thinking like an engineer, it's usually to compensate for the code being too complicated to read. I consider that a pragmatic response to a worrying failure, not something to aspire to more of.
You betcha. Think of how Woz designed a floppy disk controller that used fewer parts than other designs. That's engineering the logic.
A big part of software engineering is to engineer the logic to get the correct result as fast as possible.
Engineering is all about working within a set of constraints. Things that are easier and/or cheaper to manufacture, have clearly been engineered that way.
It can't be a coincidence that we consider CPU time and memory footprint "costs".
I definitely see where you are coming from re: 'engineering' logic. As I said before, I don't have a huge argument against this. However, for me this is where the metaphor blurs into near-meaninglessness for me. Optimization happens to be a specialization of mine, and I can't find a reason to think of it as engineering, except for the fact that I take measurements. The optimization itself is more like applied information theory. I can agree that the measurement + iteration is perhaps engineering.
Consider a fuel injection system from the 1960's. It was a mechanical computer. Was that not engineering? It was certainly designed by a team of engineers.
These days, it's software that does the same thing. Why is that not engineering?