I’m not sure which section you are referring to from the manual, where it says that is the only difference (maybe the Quick Tour, where things are necessarily brief?). At any rate, There are altogether three differences, though only two are really worth mentioning since one is “they look different”: 
- By default, stacked files don’t act like groups when you click on them, they act like text files. You have to load Corkboard or Scrivenings by hand after clicking on them. Folders on the other hand always act like groups when you click on them. So that distinction right there can be useful in that you can choose what happens when you click on a section. This difference can be removed in the Navigation options, causing stacks to act like folders and always use the current group view mode.
- The visual difference. It’s minor and obvious, but having something different around like a folder icon helps one to break up long outlines and draw the eye to key parent nodes. True, we’ve got custom icons now, but if all you need is the basics, folders are easier to use than custom icons. We can also use the difference as a form of internal semantics. I might reserve folders for major structural components of the book, for instance—what will be visible to the reader in the form of headings, page breaks and other conventions.
- When compiling you can treat file stacks and folders differently, when it comes to Formatting, and stacks are treated a bit more “invisibly” in terms of how the outline can be turned into book structure. They don’t have entries in the Separators pane, so often they can be used as “silent” grouping mechanisms in the draft—when you want to associate a few sections together without actually turning them into a formal group with a folder, that would in turn cause them to be a chapter (assuming that is what you are doing with folders). So at this level, it’s all about giving you a little extra flexibility, and that is what makes Scrivener a general purpose tool. We do not have a “chapter” object in the software, instead we define what a chapter is with the outline and its relationship to the compiler. Having stacks as well as folders around means we can have two different “types” of constructive objects going on at the same indent level.
Only in the sense of point #1 above: when you click on a stack you’ll go straight to that text, with a folder you’ll need to turn off a group view first (unless you’ve already done that for another folder).
At risk of seeming glib, I’d say the answer to that question is why would you want any component of the outline to be something you can’t write into? What purpose would it serve to have a type of outline node that merely doesn’t have as many features available to it as the rest? This gets into the concept of the program—that of being a pure multi-pane outliner rather than an embedded outline such as in most word processors, or, as you put, something more like a database or file manager.
Like I say, I don’t mean to just invert your question, mine is a serious one as well, it’s the question behind much of the design premise of Scrivener: shouldn’t text be capable of “ownership” of other pieces of text, and to be owned likewise. What “ownership” means is entirely arbitrary and will not likely be the same for every writer, or even every book, but fundamentally and beneath any implementation, it means that the text we write can also act as its own structural skeleton.
That’s the grand theory—but what does it mean practically? A few common examples:
- That’s where you put your chapter title. For those that don’t really care to use the Compiler in-depth (they just select Original and choose a file type then click “Compile”), it’s a convenient place to put the chapter title if you’re using the folder for a chapter break anyway. That way you don’t have a chapter title in the first scene, which must be cut and pasted whenever you rearrange scenes.
- Section notes. In most of our presets and templates, folders do not actually export their text, meaning that any folder is a safe place to stash notes—and it’s also a very convenient place to do so, since folders insert themselves into a Scrivenings stream. You get your section notes at the very top—scroll up whenever you want to reference them, then return to where you were writing.
- And as talked of above: where folders are perhaps used more reactively, after the fact, than up front, as a mechanism (i.e. I am making a chapter folder now vs. all right I’ve made the outline, now let’s convert the important stuff to folders).
Of course, I’m just providing a few examples off of the top of my head. The point of the matter is that Scrivener’s Draft is a full outline, where everything in that outline is a “node” that is capable of storing two different text documents (Main Text and Document Notes, three if you count the Synopsis) a Title and some meta-data. Thus, calling things strictly folders or files is a bit limiting, especially since you can at will just convert them back and forth with a simple right-click.
I’d say that in the end, whether all of that seems useful to you is all that really matters. I believe I basically do state the same thing in the manual: that we’re just giving you as much flexibility as possible, and part of that flexibility is the choice to only use as much of it as you (or the subject) requires.
Where I do feel that there is a limit to thinking in terms of “Windows Explorer” with a folder tree and files is when it comes to how useful it can be to express your book with a detailed outline (nothing new to anyone that has gone out of their way to learn outlining in word processors, but Scrivener can take it so much further since its outline can opt to be invisible to the final output). If every section of the book is broken down into the smallest topical entry, then the whole programs opens up to you. Project search becomes more precise, meta-data less vague (a keyword slapped onto an entire chapter is less meaningful than a keyword attached to a single beat, or a subsection pertaining only to the use of different vinegars in cooking). You also have more precision in your navigation and less scrolling through long sections—you get the point.
Thinking in terms of “files” fosters the habits acquired from using a file system and how most software handles opening two different files, where maintaining individual files means a hard separation between the content of those two files (you can open the both at once, but they do not cooperate). This leads to using long stretches of text in each file, because who wants to have 850 DOC files comprising their book, right? That would be a nightmare.
Nothing really earth-shattering there, but this is why the manual proposes the similarities between files and folders in the fashion that it does: it’s presenting a concept that is likely new to most people, that of the indented digital outliner, and trying to show that can be used to construct documents. That we’re not looking at a “list of documents”, in Scrivener, but rather the spine, or the map, of a single document. The more nodes you use, the better the map becomes.