LibreOffice vs Word
To give a disclaimer, I haven’t had a copy of MS Word installed anywhere since around 2012. That said, I’ve heard a lot about Word in its present state, have looked up how to do things with it, and I know some of its technical limitations from the angle of .docx production, so I know a little—and of what I know, I would say to that main point of your question: LibreOffice at a conceptual level has the objectively superior and easier to use model for document design and production automation in conjunction with tools like Scrivener.
You can certainly get to the same point with Word, but it will also probably require programming macros to avoid a lot of manual post-compile labour. This is of course how the pros do it, and how they get an author’s manuscript into InDesign or whatever is used to make the actual book. The question is whether one as an individual wants to try and replicate such an industrial-strength process for themselves, when there might be something orthogonal to that that is easier to learn and implement.
So to summarise why I’d say it is better for the typical author: the way in which it works is highly compatible with what you can produce from Scrivener, and is a better platform for post-compile production and design (in that, with a carefully prepared workflow you don’t have to do any work to get gorgeous documents Scrivener cannot make, which is ordinarily the kind of thing mainly Markdown users enjoy).
My criteria there is a bit biased toward “best practice” document design, I will admit. Thus, when I say LibreOffice’s model is superior, from that context, it is because of these three words: stylesheet driven design. It is by far the best mainstream word processor I have seen for being able to design a document from top to bottom with stylesheets. What that means in practice for a Scrivener user is that what you need from the compiler is far simpler than what you need for Word, which is not very stylesheet driven.
With LibreOffice you can push all of the design over to LibreOffice, and can invest your learning time on a system that actually does a lot of layout-oriented stuff, rather than one that does a little bit, and often not terribly well. Here is a post that goes into a little why this is a good way to work, and here is another that discussed the practical application a bit further. There are posts further down as well for context, as it was initially misunderstood that I was advocating one compile and then spend hours changing settings in LibreOffice every time. What makes LibreOffice so good with Scrivener is that you don’t have to do that. 
LibreOffice works a bit more like a desktop publishing tool, in that it has page styles. The header and the footer, whether the section starts on the left or right page in the book, even the shape of the paper—all of that is governed by the document’s stylesheet. But what makes that special is that text styles can trigger page styles, which is the secret sauce that makes Scrivener and LibreOffice good companions.
In practical terms, that means a level one heading, as compiled by Scrivener, when dropped into a prepared LibreOffice document can go on to trigger a page style, which will declare it should have a page break, starting on the right side of the book, suppress the header and use an alternate footer (just to list a few common desires—we could also draw a box around the page or swap to landscape orientation or any number of wild things). This page style itself can then trigger a different page style following it, probably a “Left Page” style, which in turn triggers a “Right Page” style following it, and so on, for alternating header/footer/offset margin layouts and so forth.
With a setup like that you can get a nearly complete design almost straight out of Scrivener, doing things Scrivener cannot do itself, by doing little more than using styles properly in Scrivener. When working that way, one uses a much smaller subset of the compiler, and rather doesn’t care much about what the styled text looks like. LibreOffice will be taking over all of that, from page numbering to chapter/section numbering to the way different paragraphs look.
From what I understand, Word requires one to be much more heavy-handed when it comes to things like that, and it is more difficult to get a “best practices” document straight out of Scrivener because to accomplish that the only good way of doing so is with manual labour (or again, macros).
You will for instance primarily be interested in learning styles, section types and layouts. That’s about it! You will have no need for separators and will want to turn them all off. The Styles pane in the format designer will largely be used to create a list of names that you use in Layouts to create “Heading 1”, “Heading 2” and so on structure. The Page Setup area can and should be zeroed out. Like I say, you’ll be learning a subset of what Scrivener can do, because less is more in this workflow.
Incidentally, Mellel is a lot like this as well. However it is Mac-only. There may be other equally stylesheet-driven tools out there, but I would bet most aren’t free or cheap, and most in that category will be industrial-strength stuff like InDesign and Affinity Publisher.
And I couldn’t let a post go without saying that realistically that is a better target than any word processor, which like Scrivener, are also writing tools, not book-making tools. But, LibreOffice is closer to a book-making tool than any word processor I’ve seen, and its PDF output is probably acceptable in terms of typesetting quality.
Markup vs GUI
Since it was brought up, for systems like LaTeX vs word processing, which includes other markup systems to be clear, I think the main difference between the two could be best summed up by putting it this way: how do you best learn how to use software?
If you prefer software that puts all of the possible options in front of you using a graphical user interface, then systems like LaTeX will probably be frustrating to learn. But if you’re like me, and you find wading through tabbed dialogue boxes to be annoying and find it easier to just search for the right ‘command’ to type into the top of your document to make your footnote numbering different, then stuff like LaTeX will not be so bad to learn.
Either way, one will expend a lot of effort learning these systems. They are all complicated because they must address almost everything people need to do. They just express their complication in different ways, and are more or less conducive to different personal preferences.
That said, one needn’t conceptualise all of the markup realm as being so difficult as LaTeX. There are great alternatives to that system out there today which also follow the same rough ideas of using marked up text to generate formatted output, rather than learning layout software to do that in a visual environment. Some are even based on HTML and CSS principles, which are easy to learn and something not unfamiliar to many (certainly anyone who has tried to make an ebook should at least know a little of that). Some systems, like Quarto and Pandoc, make it possible to tap into more difficult systems like LaTeX without having to learn much about it, and by using a much simpler form of markup.
It can be an interesting and rewarding path, and given how the workflow to get there involves plain-text files, it is often more conducive to automation than the graphical path, which more depends on developers making good import/export code and so on. But again I would only recommend it if you like the premise itself, because honestly that’s probably the main appeal to using such systems in the first place. The capability comparisons are otherwise fairly even. There are publishers that use graphical workflows and publishers that use plain-text workflows, like DocBook and LaTeX.