I’d think you would have to rework your query to get it to work. To my knowledge each property in a mongo document has a 16mb limit. Try to write your query to create one of your larger objects nested within another property to allow it its own 16mb limit. This may overcome your problem.
I would seriously be rethinking what you are querying for though. Do you really need that much data returned in each row? Can’t you filter out at least some of the properties being returned?
That aggregation query is taking all the documents in your collection and creating one document for each distinct item. The problem you are having is that the $push operator adds another entry to an array of values for each qualifying input document. That means that the aggregated document size can become very big. If each array element is 16 bytes, you only need 1M item: 'A' in your collection to exceed the 16MB document size in your pipeline.
Notes: I’ve used a string for the group _id so that you can use it successfully with Meteor’s pub/sub (using tunguska:reactive-aggregate for example) and minimongo. As the _id also includes the short_date and item fields, you don’t really need them in the group document, but it saves parsing them.
Just change the sort to $sort: { item: 1, date: 1 }. You may be able to take advantage of indexes by moving the $sort stage to the start of the pipeline.