The author is not arguing for simplicity per se, but about being able to insert a human into a system that is normally automated. The example about the ship's steering system is perfect, actually. The system is not "simple" (if I were on a ship and the steering failed, I would be clueless), but it provides plenty of interjection points where a knowledgeable human can step in and either debug or fix the issue. It's those points that should be relatively simple - the whole system itself can be as complex as needed.
Your system should be testable, debuggable and it should allow a human to step in and take control if needed. An open system is generally better than a closed one.
Humans in the loop are likely to be a source of trouble, and you will need to measure to figure out if they provide any overall benefit other than giving you somebody to blame when that trouble happens. You need to ensure that the "human in the loop" scenario is obviously worse than automation or else humans, always over-confident of their abilities, will put themselves in the loop when it'd be far safer not.
A good example of how to do this would be London's Docklands Light Railway. A DLR train is capable of autonomously going from one station to another. Trained operators are aboard every DLR train, and they have a key to a panel in the front of the train which reveals simple controls for manual operation. But very deliberately the maximum speed of the train with an operator at the controls is significantly lower than maximum speed under automation (there are two modes in fact, driving with the train still enforcing rules about where it can safely go which is a bit slower, and driving entirely without automation helping which is much slower). This underscores that manually driving the train is the way to sidestep a temporary problem, not a good idea in itself.
The DLR has had several incidents in which trains collided, it will come as no surprise that they involved manually controlled trains. Humans are very flexible but mostly worse as part of your safety system, don't use humans if you can help it.
I think what he meants by human and users is "programmers" and layers of abstractions in your code. The ability to change and go deeper when you need it.
But you example works nicely as well, you should avoid having to work at lowers abstractions, and limit the work there as well. "changing the core to adapt to new features rather than adding to the core"
Agreed, the first bit of the article isn't about simplicity as much as it is about visibility and the ability to directly control each aspect. This is very much in line with how modern SCADA systems are designed (and indeed the ship example is one of these). Each component can run automatically based on sensors and the state of its peers, or it can be directly controlled by the operator if required.
The latter part of the article talks about simplicity but doesn't seem tightly tied to the earlier part.
I considered using other labels besides "simple," like "redundant" or "straightforward," but decided no matter what word I used some ambiguity would remain. So I stick with "simple" and hoped the context would help carry the point across. I'm glad that it did, as it seems.
How would a steering system that is simpler than that look like?
I think a key element is that this system is composed of parts that have one input. That allows a human to replace a component that failed and provide that single input to the next component in line.
Your system should be testable, debuggable and it should allow a human to step in and take control if needed. An open system is generally better than a closed one.