There's another problem I run into with this approach, beyond what he describes: It can lead to an outsize amount of rework, because it maximizes the delay before you can start getting feedback from UX or any sort of exploratory or ad-hoc testing.

I remain a bigger fan of the feature flags approach. Even if it's a really nasty redesign and you have to copy/paste an entire view so that you can hack on it in the background and have just a coarse-grained switch to switch between the existing version of the view and the WIP, that's fine, I'd rather have a temporary code freeze on the old version of the view (so you don't accidentally stomp bugfixes or tweaks when switching to the new) than have a project that's big enough it can't be fit into a single sprint get stuck with an outsize risk of nasty surprises late in its development lifecycle.