Even if that is the case, it has to redo this how often? If the page counts are to be stable, I'm assuming so are page numbers? At which point we are back to this not being something I would expect to slow things down appreciably on the vast majority of actual uses.
Still, I should acknowledge you provided an example. It surprises me.
It needs to rerender everything whenever you change any setting that affects typesetting. This used to be quite annoying when trying out fonts or find the best value for some setting, but recently they implemented a better way so that it first renders the current fragment (usually a chapter), releases the UI so that you can read, and renders the rest in the background. Page counts and some other stuff are broken in this meantime.
That better way makes a ton of sense, and is what I would expect to be default. Getting page numbers is a flex that just doesn't feel necessary. As I said, I would expect even faster renders if it did present content first. Would edge case into unstable page counts, but I struggle to care on that? Make it an optional setting, and be done with it. Especially as I prefer resizing to keep the current start of page I'm looking at. Something obviously not guaranteed in a resize.
> it has to redo this how often?
As often as the font size changes.
So, never for most reads? :)
Even the few times I do change text size on my e-readers are largely mistakes. Having gestures to resize is frustrating, in the extreme.
Eh, I don't really have a dog in the fight. When I'm out and about I just read on my phone, which my oral surgeon says is too small for my eyes; I haven't asked my ophthalmologist for advice on my dental implants, but I have been reading as much off screens as off paper since the late 1980s, so any kind of sense I might once have had for the aesthetics of typography must surely have been strangled in the crib.
When I'm home, I read books.