It's not smooth. Your app goes from actual rendered content -> scaled content -> scaled content -> scaled content -> actual rendered content -> scaled content -> scaled content -> actual rendered content. Imagine an app with a status bar, where you're enlarging the size: your status bar goes from its natural size with sharp fonts, to bigger and blurry, to bigger and blurry again, back to its natural size with sharp fonts, and so on, and so forth. It's a disaster for text, where you see the exact same thing, except even more jarring because the text is likely to get reflowed.
The rapid spasming transition is really, really jarring, and objectively speaking, the scaled content looks worse than genuine client-rendered content. All this is in direct conflict with Wayland's core ethos of 'every frame is perfect'.
So it's either that, or you can leave the window contents in place at the last size the client gave you, and track the new size with an outline. Which is 100% possible to implement within Wayland.
The only benefit it has is the frame window following the pointer.
(And hey, if it forces app authors to actually think about making their clients more responsive to user interaction, that's no bad thing at all.)