"Store", in the case of MVCS design patterns, tends to lean towards storage logic. In the case of iOS, this is usually a Core Data implementation. If you create a Core Data-backed template in Xcode, you'll see the "Store" aspect of this design pattern tucked away in the AppDelegate class.
To take this to the next level, I will often create a singleton manager class that handles setting up the Core Data stack, and deals with all of the fetching/saving that is involved with the stack. As the quote you mentioned says, this makes it very easy to not only call those methods, but to adjust them if needed, as opposed to having saving/fetching calls all over the place in different view controllers.
The "Store" paradigm isn't restricted to Core Data, though. Your store may just be a web service. Perhaps you have a class that interacts with Facebook, Twitter, Yelp, or some other REST-based API. I have found (and similarly follow the trend) that these kinds of classes also have are named Manager. They are very literally managing all of the internal details so that your other classes can just put in or get out exactly what they need.
As far as obvious flaws or problems with this design pattern...As with any design pattern, the most glaring problem is ensuring that you've set up your project in such a way that jives with the paradigm. Especially with a design pattern that is new to you, this can sometimes be the hardest part. The benefit of breaking your "Store" logic out into its own class is the very fact that it makes code maintainability much easier.
What follows is my best reading of the relevant specifications and references. (I found Mozilla' abstracts about DOM levels and associated links especially helpful.) I encourage corrections or clarifications from others.
So does the DOM talk about how an XML/HTML document is represented as an object model?
Yes. There are two parts to DOM Level 1 specification -- Core and HTML. The Core DOM specification describes a general DOM that could be used to represent any structured document. The HTML DOM specification describes how to use the Core DOM to describe HTML documents specifically and includes HTML-specific interfaces.
The DOM does not specify that documents must be implemented as a tree or a grove, nor does it specify how the relationships among objects be implemented. In what other ways can the document be represented?
DOM Core does assume that the document is a tree. The Node interface is the "...primary datatype for the entire [DOM]. It represents a single node in the document tree." Node has several properties for accessing children, sibling, and parent nodes (e.g., parentNode, frstChild, etc.) that implies a tree structure. You could use a flat tree or a linear tree (e.g., a linked list), but it's still going to be some form of tree.
As George Mauer points out in the comments, perhaps you mean that the underlying model of an particular implementation does not need to be a tree. That much is true; as long as your implementation provides the functionality promised in the DOM specification, you can use whatever structure you like to provide that functionality.
Are the objects and methods within the DOM parsing engine in their own native language?
Generally, yes. In most browsers, the DOM is implemented in a lower-level language like C, and the browser supplies bindings to the JavaScript environment that can manipulate the actual representations. In fact, if you look at the question Meaning of “Moving DOM into Javascript”?, you'll see that Google is interested in switching to a native JavaScript DOM implementation (likely to avoid needing both a C++ function and a duplicate JavaScript wrapper for that C++ function; possibly also for performance gains).
what is responsible for translating from JavaScript to the native language?
I'm a little bit hazier on this subject, but my understanding is that when a JavaScript DOM binding is invoked, the JavaScript execution environment (which is itself implemented in a lower-level language like C) makes a call to the relevant DOM function (written in C/C++) to manipulate the DOM.
If you want to go deeper than that, you'll need to talk to someone who actually makes browsers.
does that mean that when you create language bindings by following the IDL, you are just creating objects in the specific language, i.e C++ that your DOM parsing engine is built with?
Yes. The DOM's IDL is language-agnostic, so that you can implement it in any language. "Writing a DOM implementation" means writing code (in a particular language) to conform to the IDL interfaces described in the DOM specifications.
Best Answer
There are a lot of overloaded terms in programming. The "model" in Model-View-Controller has nothing to do with the "model" in Document Object Model.
Arguably the DOM should have been called something like the Document Manipulation Interface, since that's what it actually is: an interface. More importantly, it's an interface for manipulating the content that gets shown directly to the user. In MVC, any code that shows things to the user should be in a View.
It's entirely correct to say that your MVC model should not be manipulating the DOM, for the same reason it shouldn't be generating popups or playing sounds: We want to keep the business entities (models) decoupled from the presentation logic.