These seemingly inescapable tradeoffs are almost always actually quite escapable if you look at it from a different perspective. You have to stop thinking about pages and button-clicks, and you have to stop using frameworks that try to do everything, box you in, and force you to architect your state-flow logic based on your visual hierarchy. This is the biggest problem with almost all UI frameworks: all your logic has to be partitioned along the lines that are set up by how your screen looks, or you're swimming upstream to prevent it. Instead, have your domain models declare how they work and interact using intermediate services, and consume those services to generate the UI as a consequence of those declarations. It's very hard, and I don't have all the answers yet, but I've tasted enough to know that it genuinely avoids this otherwise seemingly inescapable tradeoff. I'm not planning to ever build another UI (above some complexity) differently again.

Speaking of a different perspective, you and GP are describing it with different viewpoints and I'm not sure you're fully aware it is different:

GP is describing the Model and View as two co-equal things with something in between that links then.

You're describing the Model more as a foundation that the View builds on top of (and this is also how I look at it).

I like the stacked view more because it more closely matches the flow of data, making it almost explicit that what's presented to the user is a projection/transformation of the stored data. Views can't really exist independent of that data, they rely on it, while models can exist independent of the view.