I'm not sure it is the wrongway of looking at it, rather, it's another way of looking at it :-)
I wrote that a bit slyly. My point is that when you compare apple to oranges, don't make the mistake of thinking that only apples are the right way, so that when a process creates wonderful oranges for you that is an error. Or, the other way around.
I like both apples and oranges. I don't want to do without either. I like to have either on hand so I can get what I want when I want it.
In this comparison:
ArcGIS broke the data up into individual polygons, whereas the Manifold areas would need to be decomposed to accomplish the same thing.
You compared two different things, both of which have excellent reasons for being. Either result would require processing time to be converted into the other thing.
For example, if Arc were to do all that Manifold did in creating those bundled areas, it would have taken even longer to do that extra work, if, indeed, it is even capable of handling such big and complex areas.
Manifold goes the extra step to create branched areas because arranging data that way is intensely useful and convenient for interactive work. I love being able to just click one contour area of interest and immediately being able to format absolutely every sliver like that everywhere in the entire world, if, for example, I'm working on a map of contours for the entire world.
It's true you can accomplish the same thing with many small areas by using clever selection, I suppose in whatever ESRI has that is similar to SQL or to Manifold's selection tools, but that is a workflow that is not so point-and-click as what can be done with what Manifold delivers.
Conversely, I can see a use case for zillions of standalone area objects as contours. Which of those you choose depends on whether at this moment for this particular task you want to reach for an apple or an orange. Neither is bad, but it is a mistake to in either case say "oh, this one over here is not so good because you have to expend time to transform it into the other."
Manifold delivers the result it does now because that is so much better for point-and-click usage, for thematic formatting and for per-object formatting, as most people do contours. It is way easier and clearer for most people to work with tables that have only a few dozen records in them. That's why Manifold puts the extra effort into delivering that simplicity, compactness and clarity.
It's not clear if ESRI does not do that because either a) their work derives from older generation approaches that do not support the big values per-record such an approach requires [a real possibility given the legacy influence of, say, shapefiles...], or b) a preference for the other way, or a mix of both. But they do it differently and in a perfectly legitimate and competent way.
In making apples to oranges comparisons, it is not always so useful to consider separately the cost of converting from an apple to an orange or vice versa. For example, Manifold goes to the effort of building branched areas when the contour result is first created. If you don't want that but instead you want standalone areas, it is far easier and more efficient to build those standalone areas during the process than it is to later take a carefully constructed branched result and to decompose that into shapes.
Likewise, if ESRI went to the effort of duplicating what Manifold does it is quite likely it would be faster for ESRI to do that during the initial process of computing contours than it would be to take a result of many standalone areas and to aggregate them into a compact set of branched areas. In either case it is best to compute the result you want as part of the initial process.
Therefore the best way if you are interested in apples is to compare how fast Manifold and ESRI are at creating apples, and if you are interested in oranges, likewise how fast Manifold and ESRI are at creating oranges.
To emphasize, neither apples nor oranges are "better" than the other. They both have their uses.