I don't disagree, plus the Amazon metric has been quoted everywhere with very little context, so I wouldn't be surprised if it was not fully accurate.
However, there are teams that have a lot of insight into the needs of ecommerce that are investing heavily in reducing the hydration overhead – I imagine the reason for it is that in very dynamic sites it feels clunky that the user can't interact with the page until it has hydrated.
It is no coincidence that the only other framework besides Qwik that is being built around resumability is eBay's Marko 6
I'm not sure why you think MPA is somehow inherently slower than a SPA
For a complex application, data has to load in from the server on every page load – it can't simply be all bundled into the js.
In eBay's case, a MPA using their own custom framework makes sense, as they do async rendering (e.g. you can load and show the most important data in the page quickly, while ancilliary stuff can load afterwards) and partial hydration (so if a component doesn't require js, no js loads/runs)
The point is that hydration is more of an issue for MPAs since each time the page loads (on navigation), the html must be parsed and DOM objects need their javascript listeners attached.
For SPA, this is not the case after the initial page load event. Hydration needs to happen only once at startup.
eBay develop Marko and use it for their pages.
This talk between a Qwik team member and a Marco team member explains the differences a lot better than what i can https://www.youtube.com/watch?v=7XR5-qDhqGY
However, there are teams that have a lot of insight into the needs of ecommerce that are investing heavily in reducing the hydration overhead – I imagine the reason for it is that in very dynamic sites it feels clunky that the user can't interact with the page until it has hydrated.
It is no coincidence that the only other framework besides Qwik that is being built around resumability is eBay's Marko 6