It may feel like waterfall from the outside because it seems like they do a lot of planning up front and then execute on those plans, but that's too simplistic a view of what actually happens internally.
That does't stop people from doing it, though, and I think he's just trying to make sure that readers don't learn the wrong lesson (eg no course corrections! plan everything and stick to it no matter what!) from this analysis.
It seems to me that the reason Apple succeeds with a (relatively close to) waterfall style approach is the long term planning / strong point of view the author describes. The more the goalposts move, the more agile you have to be.
In the startups that I have worked with, most of them don't give nearly much time to devs.