I've been thinking about this exact question a lot.
I think it's important to distinguish between slicing by individual responsibilities vs. slicing by team responsibilities. I'll focus this answer mainly on slicing teams.
For some background: I have worked in projects with full-stack developers, single-tier developers, vertical (full-stack) teams, horizontal (single-tier) teams, and diagonal teams. By diagonal team I mean containing all the tiers needed for a story but not necessarily all the tiers in the system, and also possibly containing multiple developers focusing on the same tier(s); in other words vertical in spirit but maybe somewhat horizontal in appearance or in implementation detail.
Recently I have worked in a group that transitioned from horizontal teams to diagonal (nearly vertical) teams. It has been particularly instructional to see the same group of people aligned two different ways. It makes some advantages and disadvantages quite clear.
I'll round up my opinion so far with the following summary comparison:
- Fosters good separation of concerns and loosely coupled tiers
- Much easier workload distribution management
- Easy for specialist technical lead to manage
- Fosters intra-tier collaboration, best practices, pride, and a culture of excellence
- Aligns with natural/emergent communication patterns
- Hinders communication of inter-tier dependencies
- Enables tier "bubble" culture if unmitigated
- Difficult to take advantage of generalist leadership
- Hinders generalists
- All the parts of a user story in one team ("one stop shop")
- Specifically assists delivering n-tier stories in a single sprint (although do you really need that?)
- Fosters inter-tier collaboration and growth of generalist skills
- Supports generalists
- Much more difficult workload distribution management
- Enables poor separation of concerns and tightly coupled tiers
- Hinders specialization by curtailing intra-tier communication; it is difficult to see how a culture of excellence could arise out of this structure without adding mitigating horizontal/specialist behaviors
I do not think team membership has a one-size-fits-all solution. It seems pretty straightforward, however, that the vertical team lines up better for organizations requiring generalization. If your engineers are generalists and like working full stack, that's a pretty good reason to consider vertical teams. The horizontal team lines up better for organizations requiring specialists. If your engineers are specialists, that's a pretty good reason to consider horizontal teams.
As others have mentioned, secondary structures/behaviors that slice the other direction can help mitigate the drawbacks of either system. One interesting mitigating factor is sprint duration. Short sprints render some of the disadvantages of horizontal teams more tolerable. If you can build the backend this week and the frontend next week, that might be fast enough?
To apply some of these proposed principles to a real-world problem... I will say that the horizontal slices have worked quite well for a very real SaaS development team I've worked on that was solving very challenging technical problems in every tier (where specialization was in my opinion incredibly important), where frequency of delivery (and reliability at a high granularity/frequency) was critical to business success. Please note that this conclusion is for a very particular real-world team, not a general statement of superiority of horizontal slicing.
One caveat: I am probably biased against believing claims of generalist abilities by any individual in the modern software development world without significant proof, although I have known a few rare exceptional generalists. I feel that generality is a tall (vertical?) order indeed, particularly as each tier grows in complexity and with the proliferation of alternative languages/platforms/frameworks/deployments, each meeting different needs. These days especially, a jack of all trades can quite easily be a master of none. Also, anecdotally, I find most individuals want to specialize quite a bit, again with some exceptions.