The way I understand it, the new Groups feature is meant to mitigate this problem, or eliminate it entirely in some cases. Since groups can be “focussed” you can narrow down the browser and the filter browser to only showing that one area of the project. Thus, multiple related real-world projects can be easily included into one large project without fear of clutter. Since groups can be nested, they can still be useful for large-scale organisation within a project as well.
In playing around with it, it appears groups can only contain other groups, filters, and collections. Not “floating” documents themselves. I’m not sure why that is, maybe because there is no superior way to indicate that in the document browser.
On performance, as with Scrivener, the actual mass of content within a project is of little consequence in how speedy the application will run. It’s more a matter of how much you have open at once. In Ulysses, that’s tabs; in Scrivener, that’s an Edit Scrivenings session (and I think on this score, Scrivener has the upper hand on how much can be “loaded” at once, but I’ve never really tested it completely—I also prefer the in-line approach to the tab approach, but that is subjective). So from a performance stand-point, there is little reason to shy away from dumping multiple books into a single project. It’s more a matter of whether or not such inclusions will make the interface awkward. I think the group focus, which in essence makes the interface look like only a small part of a large project is actually present, would do the trick.
Same goes for Scrivener (though the Binder will always remain “fully loaded”). There is nothing in the interface which prohibits you from having multiple books stored in it, with the one exception of the MultiMarkdown meta-data settings (you could also make a case that having labels and status universally applied would prohibit—but so long as akin projects are grouped together, that shouldn’t be a problem. This issue also applies to Ulysses). The ability to rapidly isolate any part of the draft during export makes this easy. Collapsing and expanding sections of the Binder, while the parent item will remain visible, effectively removes the distraction of the other projects.
So on this particular topic of using projects as “meta-projects”, I would give Ulysses the leading edge, as they have after all stepped into the arena of explicitly supporting huge projects. The ability to completely isolate a sub-project in the browser/binder, and just as easily export only focussed areas is quite powerful. It’s a subtle lead more in the area of refinement. I don’t think (with the exception of Binder focus) Scrivener is markedly weaker—just not quite as “tuned” to the notion as 1.6 is. The one area that does feel a little strange is in the colour labels and status labels. With the browser now adept at handling multiple projects—that interface feels a little dated and restrictive.
And all of this, of course, assumes that one can find an affinity for the somewhat bizarre mechanism of employing structure separately from the products of that structure. There are pros and cons, no doubt (intuitive multiple associations being foremost), but it is unorthodox and requires a little acclimation period. If a person simply cannot get comfortable with having containers in one list and children in another, it doesn’t matter how refined the tool is.