I’m not sure where that claim is made—we are quite careful to leave any implications of publication away from what the core software is meant to accomplish. It fundamentally remains a pure writing tool.
The only main exception is its ebook output system, which is probably right up there in terms of what other tools are capable of. You have full control over the CSS, and with a knowledge of how content is produced, deep control over the HTML structure itself. One could do just about anything they want for an ebook, rivalling even lower-level tools like Sigil, or assembling book manifest content by hand in a coding editor.
For the rest though, RTF and PDF and all that—yeah, you aren’t really supposed to be trying to use this as a desktop publishing tool. If you can make it work for what you need, all right, but it’s about as misguided as using MS Word for publishing, frankly. It’s not something anyone in a professional capacity as a book designer would do.
Or it means exactly what it says: that these are technical limitations in the programming toolkit rather than design decisions. 
One can be aware of what is proper versus what is not possible, all at once. In fact I would say that the paragraph you quoted wouldn’t exist if one were unaware of what is proper. That a warning is given here at all, should be a strong indication there is an awareness.
In some systems, sure. That isn’t a universal statement though. In some systems listing tools are general purpose and not coupled with styles, so to speak, but rather the stylesheet changes how they work from some central definition. XML and LaTeX for example, do not have “paragraph styles” in the sense you seem to be using the term, and a list will be simply a functional construct which can have its appearance and layout modified by the applied stylesheet or document class. Indeed, within how these systems work, to say that a list is a form of paragraph is illogical, much like trying to assert that a caption is a form of paragraph, or a figure.
It’s not so crazy once you consider Scrivener’s design intent here: that one needn’t be forced into learning how to use styles unless they really want or need them. It’s designed to be as equally useful to writers who have no clue what any of this stuff is about. Someone can just type into the editor, never once changing formatting settings, and then easily switch between Manuscript-Courier and Paperback, achieving a radically different document design based on whether they are proofing for their own comfort, or submitting the formal manuscript. I.e. it achieve what styles in word processors do, but without the edict that everything must be styled in order to accomplish that.
It is also designed, incidentally, to be easily transformed into a properly styled document on output, if that is what you need. You simply apply a body paragraph style to such text in the compiler. Now, I would say that in general it could use some improvement there, and we could go into the many ways in which that is true—but these would all go back to my advocating for using Scrivener’s technical systems of output (like DocBook and LaTeX) if you really need well-formed documents. It’s either that, or spending a week or two polishing the document off in the final environment (just like you would have done in v1).
Well now you just have me confused, as I wouldn’t consider Word to be any sort of pedestal upon which desktop publishing design should be referenced.
At the risk of sounding like a broken record, that may be how Word solves the problem, but that is not how the problem is solved in other publishing systems. In LaTeX for example, I don’t use “paragraph styles” for the main text, the main text is much closer to Scrivener’s no style, in fact. The indenting and spacing policy for paragraphs is a transformation done to such text dynamically, based on the context of objects around it.
To my mind, this is a much more elegant approach than Word’s anyway. For how I work, I can have a single block of text, and if I drop a block quote or figure in the middle, the indentation and padding policies of the paragraph following those elements automatically adjusts when the document is typeset. With Word I would have to go in and manually assign a “Body - No Indent” style to each paragraph following such elements, and manually correct those assignments if elements are inserted or moved around, later. Yuck.
Crucially, Scrivener is much closer to that ideal, where you don’t bother with petty little details like formatting indents in the writing environment. Rather there is a policy switch in the compile settings which determine how indenting works globally, upon all body text. That is what a Format is. So to say it shouldn’t be using Formats to drive formatting is a very Word-centric way of thinking.
But that is exactly how Scrivener works. You may not be making the conceptual connection here, that the compiler is in a large sense the stylesheet application phase (and as noted, it can be literally that as well). You write without thinking about any of that stuff, and leave these details up to the compiler.
Overall it sounds to me as though you are familiar with a different kind of document design that Scrivener was based upon (namely, WYSIWYG), and have come to believe that is the only way books are made. Scrivener is, as I’ve described above, much closer to the DocBook XML / LaTeX / HTML / Org-Mode way of doing things, where the text itself is defined structurally, purely for its semantic function and without any regard for formatting. As with these systems, the actual document design is implemented as part of the production phase, as a mechanism you run by feeding content through it, and ending up with an output document of some format.
To conclude, I wouldn’t say that much has changed since version 1, at a philosophical design level. It’s pretty much all the same, the main difference that has arisen over the past decade is that it is now much more capable of taking your raw content and turning it into something much closer to how you might eventually want it to look. It removes some of the busywork, if you are inclined to have it do so—but ultimately you could use it just like you did version 1, very simply, and without learning much of how the compiler works, and then spending that time instead manually formatting the document in a DTP.