To a degree, I would say what you are referring to is more a matter of looking at the wrong tool for the job, and criticising it for not doing well what it isn’t supposed to be doing. Ebooks are more than just the kind of .epub file Scrivener makes, and can include fixed designs that are much more conducive to the type of books you are referring to, I think—same for textbooks, I would say, which benefit from stylised page layout.
As for what this tool is, a reflowable ePub, it is optimised toward long form text that does not depend heavily upon layout to convey its information. General non-fiction, prose and the like, all are mainly a matter of paragraphs and simple offsets and adornments here and there (like quotes), and enough typography to make some fancy headings. It’s a format that is ideal for presenting content in a form that can scale the font size dramatically, and be displayed on a wide variety of screen sizes and shapes. That implementation factor works very strongly against fixed page layout designs.
The technology that is being used, itself, is capable of a great deal more (including fixed page layouts). It’s the same exact technology you are looking at right now on this forum, and that’s a relatively simple example. Software can be made with it, and in fact most browsers (inside of the rectangle of the window frame) are built using that tech as well, along with numerous popular tools.
Your typical ebook reader couldn’t replicate this level of design and fluid implementation however, because its resources are much more limited. For that reason, the emphasis of implementing the full spectrum of what this tech can do is biased again toward what benefits long blocks of ‘standard’ text.
That said it can do quite a lot beyond that, and shouldn’t be underestimated:
Or stuff like putting a couple paragraph into a box frame without killing pagination.
Designing box call-outs in ebooks. This thread covers both “margin box” style as well as full-width, further down. The only way that would kill pagination is if you make it do that on purpose, with similar CSS codes like what we use to keep a figure and its caption together.
Or even having a simple full-page illustration somewhere and still filling the pages before and after with text fully (i.e. anchoring it to “next page break”).
Don’t quite know what that means, with regards to anchoring the text, but that sounds like multi-page typesetting which is of course not something an ebook reader with flexible font and text layout settings could achieve. That takes a lot of physical work to do right, usually by hand, but even what can be automated is very processor intensive and requires pre-rendering, where as ebooks render pagination on the fly (to the point that you flip back and forth between pages you might sometimes notice word wrap changes).
That aside, full page illustrations are easy. That post goes over one type of break, the page-break-before attribute, but there is also a page-break-after. Combine the two together on your styled figure element and now you have something that sits on its own “page”.
Margin graphics?
Same as margin text boxes, and similar as well to how you would make a drop-cap.
Page headers?
That one is fair, but I would say that, unlike the above examples, is something definitely over the line of what reflowable ebooks are meant to do. As with line-height, text column width, body text font and other overall presentation matters, the ebook reader is meant to be responsible for running header/footers, and in most cases that’s the right answer too. The ebook itself would have no way of knowing what “page” it is on, for instance, which is the main reason you would want a header or footer anyway. The ebook reader on the other hand is going to have a pretty good idea of how far into the work you are.