I think people need to understand publishing is complex and it's not readily transparent.
Depending on the specific "error," there's usually at least two possibilities.
First off, when we talk about print publishers, note that their specialty is
usually print (various publishers will specialize in electronic publishing as well but as far as most of the imprints of the Big Six are concerned, it's print). So their editing process will follow this trajectory, with eBook publishing tacked on later in the production cycle. (This doesn't necessarily make this wrong or a bad thing, but it's necessary to understand this to understand where errors crop up.)
One of the benefits of a traditional publisher is "editing." This is, in a way, a misnomer because there are several types of editing involved (which may require several different editors or a few editors doing double/triple duty of different roles). I'll skip Developmental and Substantive editing (it's an important step but the reader won't really know what the editor did and didn't do--and making the right call is always going to be subjective) and as far as errors are concerned, skip to Copyediting and Proofreading (note: they are not the same!).
Copyeditors take note of errors. However, depending on the hierarchy/contract/deadline (sometimes the publisher makes a judgment call on who gets the last word), some errors go through, either due to the copy editor or to the author (again, who has the last say depends on the hierarchy of the publishing house and the particular set of circumstances). Theoretically, there should be a perfect manuscript but that's an ideal, perhaps even naive situation (especially with a looming deadline). Instead of a book ridiculed with a few hundred errors, it might just end up with just a dozen, thanks to a good copy editor (which isn't to say an editor doesn't strive for perfection).
Proofreader is usually a role in print publishing. They compare the proofs (the pre-print run output from the press) with the manuscript, making sure they're identical. Arguably, especially for print-to-ebook publishers, there's a new role to be filled with proofreaders who check the eBook against the print copy. I work for a company that does professional conversion and this is included in our service. But suffice to say, if the text of the print book is the same as the eBook, the proofreader did their job. (And if there's a screw up, well, it could be the proofreaders's fault, or the retailer's fault, depending on its submission process. If there's an error in Smashwords or Amazon, it's possible they're at fault, especially when you're familiar with their process. If it's an eBook from Barnes & Noble or iTunes, it's the publisher (and while it's annoying how long iTunes takes long to publish or get approval, they actually check the document to see if it meets all their requirements before publishing).
Then there's the actual conversion of the document, whether to ePub or Mobi. If you use conversion software, the most atrocious being PDF --> Calibre, then the document WILL HAVE errors. Publisher's fault, or whoever they passed the conversion job to.
Of course even if the conversion was done right, there should be a target platform in mind. Not all ePubs are equal. If you look at the ePub submission guidelines for Barnes & Noble vs. iTunes for example, they'll have different specs for embedded covers. Apple's iBooks also has different capabilities (supports Fixed Layout for example) than the Sony Reader for example. (One example is embedded fonts: not all readers support embedded fonts.) Anyone who's coded HTML circa 1990s will understand the problem of not knowing the reader's resolution or web browser (Netscape vs. Internet Explorer have different outputs for example). Theoretically, publishers should test it against every device but that's also not realistic (just count the number of Android phones out there for example). The best solution is to test it against major platforms. (So if the ePub works in one device but not in another, we can't really say the publisher didn't do their job that well, especially if it's an uncommon device.)
Having said that, there are signs when someone just ran the document through a meat-grinder as opposed to effectively coding it. If you suddenly see dashes in the middle of a line (i.e. "hesi-tate"), that's probably a result of this print layout which the conversion software didn't properly render:
Not the retailer's fault but the converter/publisher.
After that, there's the submission process. Smashwords and Amazon have their automated process, which can lead to some errors, depending on the source file. Even a theoretically clean and "perfect" file can end up with the occasional error, and sometimes, there's no way to fix this, or discovering what caused the specific error isn't readily transparent. What can be hard to determine by the reader/consumer is whether this error was present before the file was submitted to the retailer (publisher's fault), or after (retailer's fault).