I am not sure I agree with all of this. I worry that the article encourages you to dumb-down software so that your users feel completely helpless. That is the opposite of what you should do. Your users should feel enabled and encouraged to explore and experiment. Sometimes they may encounter jargon, but if it ultimately helps them gain a better understanding if they choose to research it more, I think it's helpful. There is a difference between saying "the file is corrupted, and there is nothing you can do" and "the file is corrupted, and you are too dumb to fix it so there is nothing you can do". Omitting details in the error forces users into the second class; even if most users are unwilling to google for a solution, you need not remove their ability to do so. (And in fact, most of these cases are the developers projecting -- the problem is not that the user did something wrong, but that the programmer messed up the implementation. Why should a file be corrupted when reed solomon codes exist? Very rarely have I seen a case where something was so damaged that it could not be recovered; rather, the engineers chose not to design in proper error recovery. Then they blame the user for a disk sector going bad when the engineers know full well that disk sectors can go bad.)
The other thing I think I agree with is the philosophy on designing complicated operations. Every operation a user performs should leave them with no question as to what the outcome will be when they click the Big Red Button. And they should be able to painlessly undo it. Imagine typing without a backspace key. Your words per minute would be near-zero because of the fear of making a mistake. Undo is essential.
The lack of transparency around state changes is something that makes users hate software. Who will this share button share with? What does "make my YouTube comment publicly accessible" actually mean? Users don't know, then they make the wrong decision based on incorrect information, and get mad -- and rightfully so. We blame the user, but it's our fault for laying hidden traps. You can implement social media without tricking users, but we choose not to.
I see a lot of people fall into the "great is the enemy of good" trap with regards to undo. They see some operation that creates some immutable effect on the Universe, so the only remedy offered to the user is "email the dev team and we'll try and fix it." This is a pain for the dev team and a pain for the user. Yes, there are certainly permanent changes that software can make. Send an email, launch the nukes. But those should not be barriers to letting users undo. If they want to undo something that sent an email, you'll just have to send another email apologizing. That is all the development team is going to do when they have to manually fix it. Nukes can be killed while they're in flight; better to have some fallout near the launch site than to start World War III. And yet, we consistently fail to offer undo in most applications, so users learn to be very scared of doing anything, and that fear prevents them from accomplishing their goals. That's our fault, not the user's.
I have seen this all in action at work. We have something that is a "big red button" (we're an ISP, it's the "change service plan" button). People will not click this, and it's because they don't know what it will do. If we said "clicking this will cause the customer to pay $x a month, with the next invoice being sent on 12/01 (click here to see a preview), and their bandwidth profile will be set to XMbps in the next 30 seconds", then people would click the button, because they know it will solve their problem, rather than create a problem.
Anyway, you have to give your users understanding and the ability to safely experiment (which is how you gain understanding). That is what makes software a tool to enhance productivity, rather than an annoyance that makes the user do extra work. Just dumbing down your error messages isn't going to cut it.