I guess what I am not sure about is whether those are really differences in kind or just degree. Let's take for example a WWII-era torpedo. It is effectively programmed mechanically without software. It cruises at a given depth and under certain inputs decides to explode. Similarly unmanned cruise missiles have been around with similar criteria longer than we have thought about these things in terms of software.
It is true that software allows these decision trees to be more complex than one gets with purely mechanical systems but prioritizing inputs is a basic strategy in safety engineering. You might have a riding lawn mower disengage the blades when the rider stands up for example. On the other hand, if the pilots die in a modern fly by wire airplane, it will still eventually crash just later (see Helios Airways 522). To a certain extent you have significant issues with human troubleshooting and highly automated systems (see this article in IEEE Spectrum) because of complexity but I am not sure how software makes that significantly worse directly other than just increasing complexity.
The software you speak of is an abstraction that doesn't exist in the real world. A more realistic view of software is that it provides a mechanism to adapt machines to changing needs. If we are going to disregard speed there's no real reason that electro-mechanical systems could not do anything electronic systems can, just slower and if speed is a criteria you are limited to the physical requirements of the systems today.
This is also where my disagreement with the guy promoting that book is, namely that software exists in a context, teams don't just go home (someone has to maintain and manage the machine). Software in the real world doesn't just run itself.