I feel as if the key observation there was "and where state outlives the view".

In SwiftUI an instance of a "view" is simply a definition of the desired screen layout. Views are transient and continually being rebuilt and reevaluated when state is changed and updated.

SwiftUI will take the generated definition and build the actual interface for us, dependent on platform.

But as such, it's often a good idea to separate the view's state from the view's definition, especially if that state is complex and would benefit from testing to ensure application/view logic and behavior is correct.

Not every view requires a view model. But complexity can grow to a point where simple composition isn't going to solve the problem, and you don't want to embed and intertwine business logic with view layout code.