sure, but html isn't only used in a browser context. I have a severely under-powered ereader that I use to read epubs (html). It already takes ten seconds to paginate on first open and font size changes. I can't imagine how long it would take to non-naively wrap lines
I don't know why you'd expect an ereader to do a full text optimization of a book, though? Pick the starting line and layout to the next screen's breaking point. If needed, consider if you left an orphan for the next page and try to adjust that into the current screen.
Are there ereaders that have to typeset the entire text of what you are reading? What is the advantage of making the task harder?
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.