Well, that is why a lot of people transition to Word (or some other format, like InDesign, DocBook or LaTeX) during the final phases of the project. The software was never really designed to go any further than a “first draft”. Over the years it has evolved, and become more capable of generating useful end outputs, self-publishers like these features, but for the rest, it’s mainly the sync options, which becomes personal and situational choice, whether editing can be done in the Scrivener phase of the project, or if it needs to be moved to the Word phase. Eventually, if you’re in conventional publishing, sciences, etc. etc., that’s where you are going to be—it’s just a matter of when.
The few tools and methods I mentioned above can help some authors extend Scrivener into the editing phase. If for example you were the type that writes 25 chapters as 25 files, then using the folder sync feature might be perfect. But we don’t really have a solution for people that work differently from that (or are working with people unwilling to edit in smaller chunks), meaning they’ll have to transition earlier.
It’s a bit of a technical problem, if you’re curious. There just isn’t a good way to compile a document to a normal editor/collaborator-friendly Word compatible format, that can also be “smart” enough to tell Scrivener where the individual pieces should come back to, within the project. With the external sync feature, we can do that in the file name. Part of the file name is a code that links that RTF file back to a particular piece of your outline. Placing an invisible code into your document to mark these barriers would be very risky. What if your editor accidentally deletes or moves them? You might think of a visible solution then—something in the text, but this is risky as well. You have to carefully explain to everyone working with the document that these markers absolutely must not be altered, and if sections are moved you have to be careful to move the associated marker with it… etc. You can see the problem with that idea, I’m sure. 
So to have some output that is editor friendly and works with Scrivener in terms of seamless synchronisation, is probably not possible with today’s technology, the way it is. Maybe we’ll think of something, but so far nothing really solid has come out of these ruminations.
Well thank you for that, and like I say that’s really where the focus of this software is. It’s on the composition, research and internal editing phase of a project. That’s where the huge majority of development time and thought goes into. The design intent of Scrivener is based on the concept that because the creative writing phase is most often the majority of any writing project, in terms of time—having a comfortable creative writing environment is thus important. What one does with the project after that point is up to their own personal needs, and maybe even that particular project.