Sprints are less about categorizing the incoming work, but partitioning the outgoing work, to establish a quick feedback loop. This should in theory ensure that risks are tackled early.
The outgoing product is nevertheless fully determined by the incoming work being done. It would make more sense to group a set of tasks into a deliverable than a time period. You have to do that anyway to deliver anything coherent.
There are two arguments against grouping as a deliverable:
1) sprints are (supposed to be) predictable. So you know when to expect something and can plan other activities around that date.
2) (the more important reason IMHO) a sprint enforces early delivery, where features are rough and not very comfortable to use, but it’s already visible how it will look like. That means feedback can be collected and fueled into the next planning. The assumption is that it’s easier for people to talk about hidden assumptions when they interact with the software, than when they write specs