Your ebook readers get a lot of hints from the ebook file about how to present the material---I am light on details, but I believe them to be significant. It's true that there's no human there checking the typeblocks for rivers and orphans, but I can tell the difference between an ebook file produced by Calibre and one which a human has had a hand in, I happily pay my $13 for the latter, and woe betide the publisher when I discover that I paid $13 for an automated conversion. (The most egregious was a math book which OCR'd the formulas---from a book which was evidently set for print in LaTeX.)

When I'm translating plain text (Markdown-ish) input to LaTeX, I spend a bit of time going through by hand making sure all my formatting has converted correctly, any accents or non-roman characters are correct, the single- and double-quotes are correct, I haven't accidentally copy-pasted any ligatures, I have included hyphenation for nonstandard words, I've included any relevant non-breaking spaces, figures and headings and captions are flowing correctly, etc. etc. And all of these are still necessary when producing an ebook.

It's maddeningly detail-oriented, but the results are really noticeably much better, and in many cases make the difference between the text being readable and not. It's a bit like the cue dots at the movie theater---if you're not looking for them, you don't notice your uninterrupted experience unless the projectionist screws something up.

That also applies to code, I've seen some ebooks that have blocks of code formatted like they exist on a blog instead of in a printed environment. It made reading them a pain because code snippets were word wrapped badly, split over multiple pages, and you'd get pages and pages of code.

Given that ebooks are electronic, perhaps they could use some sort of pop out window for larger code snippets, so that they could be scrolled rather than in page format.

Most of those issues I mention are exactly the kinds of issues which pull the reader out of the text, even though he may not be able to pinpoint exactly why. Certainly often when I use Instapaper to read a web page or Calibre to convert ebooks I can read through the issues if I try hard enough, but it takes more effort than reading a well-produced book, and I somewhat regularly give up on automatically-converted texts because the issues are just too dire.

(Some of my other favorite conversion errors: Endnotes or references not hyperlinked. Chapters and other headings not correctly marked-up. Page numbers or other irrelevant header/footer material not stripped. Footnotes, margin notes, or other relevant header/footer material stripped. ...As you can tell, I'm great fun at cocktail parties.)

LaTeX can only do typesetting when a human operator makes it happen. Human operators for LaTeX tend to be fairly expensive, I dare you to try and hire one.

Or could, oh, horrors, the authors, editors, and proofreaders learn to use LaTeX themselves so the typesetter could just check the final document for errors?

Hi, LaTeX copyeditor and typesetter here. The bane of my existence are authors who know just enough LaTeX to be dangerous. First, almost all of their formatting work is the first thing to be thrown out. Second, authors are strongly incentivized to learn the bare minimum of LaTeX to do what they need, and to copy-paste furiously whatever stuff they find on the net. You have to remember that (La)TeX is both a markup and a programming language. Can you imagine spending your time reading code written by a copy-paste monkey? I can, and don't wish you the pleasure.

Sure - for highly specialized stuff. But, let's not pretend that 99% of the published work couldn't be well served by standard LaTeX templates and a little effort of learning the basics. If that is too much, then how do they send you the formatting specifications anyway? In some custom, poorly self-invented format?

This comment could so easily be PHP about instead of LaTeX, your pain is shared.

LaTeX is fine for putting out pdfs. It's not a sufficient skillset for putting out an ebook in any other format. It is still a pain to put out a math-heavy book in a wide range of formats. I would say that Softcover (Michael Hartl's effort) is making that a lot easier, but I can't use the full range of LaTeX there (for reasons discussed elsewhere in this thread) and I still need to visually check every format to make sure that formulas are typesetting appropriately, because I'm trying to push the boundaries of current implementation -- and that's just in writing about probability and linear algebra.

In addition, if you really want to put out a quality product you have to be aware of how each e-reader renders the stuff you send them. Different e-readers process the same file differently and not all support the promised features of epub 3.0. It's best to know up front what each supports in terms of images and scaling, and then write with that in mind. Again, far beyond latex.

Division of labour tends to increase efficiency. Do you really want an author spending hours reading LaTeX tutorials, or do you want them to get on with their personal specialty and let a typesetting specialist do the typesetting? Either way the ultimate cost is going to be similar.

But the problem is that their personal specialty is not valued much, so if they want bread on their table they better augment it with a complementary specialty.