Scope creep happens when you discover new requirements after defining a project scope and delivering an estimate. The type of analysis outlined in the article is helpful to define a sane and reasonable scope upfront, to hopefully avoid creep down the line.

It's in the article:

> The goal isn't to fall into a feature rabbit hole, but rather to understand your assumptions about the project. If I don't do this exercise and I try to build it, then I will often run into two or three crux issues that I could have easily known about from the start. Don't go implement every feature idea you come up with from this exercise!

This is only true if you believe software development to be the practice of slavishly implementing ill-defined requirements regardless of what the user actually wants.