I don't know about this author's intention, but in general with design thinking frameworks, the idea is not that each step must be followed rigidly in order and never re-visited. It's more about calling attention to the importance of each part of the framework. Once you know all the inputs needed for creating a great product, you can seamlessly move back and forth among the phases, iterating until you're arrived at the solution.
I agree. In waterfall, you close the 'design door' behind you when you go into implementation. There is nothing wrong with taking a phased approach as long as you keep that door open for the inevitable changes you discover while implementing.
In fact, that's the way it should be. There is no human endeavor that does not benefit from an understanding of how something should be done, before it is attempted. I'm not sure why some seem to feel that software engineering is somehow special in this regard. I can't count the number of times we have had people shout down attempts at serious engineering design, often by using the term "waterfall" in a derogatory manner.
Not if you call the understanding and design processes a "design sprint"!
As someone else said, the individual phases can be huge, which is why in large projects the first step is often to break down large business needs into more manageable chunks, each of which can be worked on seperately, either linelarly or by multiple teams. In a healthy process as the work progresses it is used to reevaluate previous decisons & designs. So basically agile.
Essentially, yes. I find it implausible the PMs have a deep enough understanding of a product to be able to elicit technical requirements in the beginning without proof from a prototype or UX research. I personally prefer a Lean UX or Just in Time process where understanding, design, and build develop in smaller increments.