An .epub is already what you describe; it's a .zip of .xhtml, images, and supporting files you edit directly seen in the sidepanel: https://i.imgur.com/tdCGcqS.png
An ebook editor just entails helping you edit those .xhtml files in a slightly more domain specific way, generating a few extra files (like table of contents), and producing the distributable zip.
Though I may have misunderstood which "container format" you were referring to.
No, what I'm describing is a single .html (or .xhtml file, if you like), compressed and sent on its way. Editing it as a series of xhtml, css, img, and manifest files makes perfect sense -- it allows a human to craft a book using the level of tooling that makes the most sense for them (from a word document to raw html to markdown to more sophisticated tools) but all of those tools can then retarget to a monolith that is easy to define and consume.
They do; probably xhtml/XML is not really an ideal format because it isn't easily linearalizable, but if ereaders are using a reduced set of the functionality, then they can probably safely assume that they can just split the file at a <p> or <mpb:chapter> tag without loss of fidelity, and just consider that all style-related content needs to occur in <head>.
My comment below has some remarks on pagination and reflowing that mean that a reflowable HTML file capable of being rendered by an ereader is likely subject to certain restrictions on the content to make it work. There would probably have to be a one-time indexing job (noting paragraph and chapter breaks to allow random-ish access into the file) but I think that's not crazy even for a very large document.
An ebook editor just entails helping you edit those .xhtml files in a slightly more domain specific way, generating a few extra files (like table of contents), and producing the distributable zip.
Though I may have misunderstood which "container format" you were referring to.