HTML and EPUB work not great, but very badly for scientific or technical papers or books.
No two readers render them alike, and they typically are much uglier and more difficult to use than books (sometimes even the same book) in PDF, DJVU or ODT formats.
I read a very large quantity of technical documentation and I always avoid EPUB and HTML like the plague. I use such formats only when there is no alternative.
On Linux, mupdf is a decent EPUB reader, which is very fast and it usually does a better job at formatting pages than most other EPUB readers that I have tried on Linux.
For fast navigation and searching, especially in technical documentation with hundreds or thousands of pages, it is very useful for the document to be well partitioned into pages and the page layouts to be well designed, like for a printed book, even if this may seem unnecessary for a document stored in a computer.
HTML and EPUB documents are seldom divided in uniform pages and the position of various elements, like tables or figures can vary between readers or even with the same reader in different circumstances, so when you search various things you are slowed down in recognizing them, because they may not be in the position where you have seen them previously. Moreover, in HTML and EPUB documents, depending on the reader, the size ratios between various elements may be inappropriate, making the pages ugly and/or hard to understand.
All the defects of HTML and EPUB documents are caused by the fact that the writer of the document normally does not take full responsibility for the appearance of the pages, delegating this to the browsers/readers, which seldom do a good job for scientific/technical documents full of formulae, tables and figures.
This may be fine for normal Web pages, but it is not acceptable for technical and scientific documents.
In theory, one could design carefully HTML pages and the associated CSS files, to be rendered deterministically, but I have encountered very rarely such documents.
I understand your point that you want a fixed presentation layout and pagination. I prefer to be able to responsively resize the document and to follow the ToC instead of pages. I've yet to see documentation that's thousands of pages long that doesn't include a very detailed ToC. For me remembering "section 8.3.16.2" is better and makes more sense than remembering "page 1292". I've had to read scanned math books years ago and I remember using some PDF reader to put bookmarks that correspond to the ToC, so I'd put "2.5.1.2 - Theorem about X" in the sidebar. That's how I was able to actually go back and forth easily. With just pages it would've taken me tens of seconds to locate a theorem (or lemma, proof, definition, whatever). And it was a dense book, so I had to constantly go back and reread stuff. But I agree that PDFs can, and often do, have ToCs, too.
> the size ratios between various elements may be inappropriate
I can't recall having this issue on websites or on EPUBs. What kinds of elements are we talking about? HTML and CSS are pretty good at keeping sizes from what I've seen. I agree that there are many EPUB readers, most of them very unpolished. And perhaps there aren't EPUB readers that are good at everything, yet.
For formulas, MathML and other tech has been satisfactory. I was able to find this basic math paper arXiv uses as a demo for their HTML papers:
https://ar5iv.labs.arxiv.org/html/1910.06709
It doesn't have figures, but the math is rendered perfectly. I can easily remove the "justify" style and increase and decrease the letters. If it was a long paper, it would've been nice to have a clickable ToC, but most EPUBs have one.
I think that right now most EPUB readers and some HTML renderings are bad, but I believe they'll get better.
While browsers like Chrome and Firefox normally render very well on-screen any Web page, it is enough to give them the "Print" command for that page, to see in most cases a badly rendered page, where the size ratios of various elements are bad and they overlap or are mis-positioned so that the "printed" page is completely unlike what the browser shows on screen.
The way how the "printed" pages look in Firefox and Chrome demonstrates the same rendering problems that appear in most EPUB readers.
I have no idea which is the cause of this, but the bad behavior of "printing" in Firefox and Chrome has existed for years. Not all browsers behave the same, e.g. Vivaldi usually is much better at generating "printed" pages, than Chrome, despite being derived from the same code base.
Perhaps the great differences between on-screen rendering and "printed" rendering is caused by the fact that badly designed HTML/CSS might specify some sizes in "pixels" or other such inappropriate units, instead of using length units, like points, inches or millimeters. Then when rendering on different media the size ratios are corrupted.