I get that, but even if you're initializing it as a root view now, doesn't mean that it forever going to stay a root view.

Case in point. We just added a view modifier to a project that captures the actual view screen size and propagates it as an environment variable. That modifier is applied to the root/content view and it changes on screen rotation, which now causes a root view refresh.

If we'd made your assumption and not paid attention to the internals of the view our root view would now lose state on a screen rotation.

Further, and as I indicated, your example code has a bug in it should they start typing and then scroll that element off the screen. State lost.

Finally, you're performing an unnecessary heap allocation and rebinding of your VM every time one of those items is reinitialized.

There's no reason whatsoever not to use StateObject in both of those cases.

You're making a lot of assumptions that may not be true and that may not hold true in the future, and you're avoiding StateObject, as near as I can tell, simply to be avoiding it, thinking that you're beating the system somehow.

Unfortunately, you're not.