Spritesheeting is a fundamental tradeoff between low memory use but poor performance (every single image is separate), and high memory use but excellent performance (all content on a single huge spritesheet which is always in memory).
C2 has a major limitation in its spritesheeting engine: it cannot combine different objects on to one spritesheet. This puts it a long way towards the low memory but poor performance end of the scale.
C3 improved the spritesheeting engine so it can combine multiple types of objects on to the same spritesheet. It also analyses the layouts in your project, identifies the types of objects that tend to be used together on layouts, and uses that grouping for spritesheets. This is aimed at making sure when a spritesheet is loaded in to memory, there is minimal waste from having to load objects from different layouts that aren't currently in use. This is IMO a better compromise and is closer to the middle of the performance/memory scale.
However in some cases, particularly if you have not paid any attention to the way Construct's layout-by-layout memory management works, the memory usage can increase. For this reason we added a property to help control it. Further, given most devices have loads of memory these days - 1 GB can probably be considered low-end, and any image memory use under 500mb is probably no issue at all - it seems appropriate to optimise a bit further towards the high performance end of the scale.
The main downside is people think this is some kind of fault, as in this thread. It's not, it's an intentional part of C3's design.