As a full stack I feel capable of serving as an architect on a team. I am not sure if I could feel that way if I only honed in on one area.

So I think at least one full stack (architect) kind of person on a team is certainly beneficial.

As far as an entire team of full stacks? I'm sure that would be effective but it may cost a lot of money to have all that talent, where perhaps some tasks could have been done by a non-FS. Also there is the issue where specialization is needed in a certain area, and FS usually don't offer that.

So I don't think it would be a mistake, but it may not be as optimal as having a mixed bag where you have a handful of full stacks and then some dedicated FE and BE folks.

To answer your questions:

Do they work: yes

My experience: I'm biased, but I prefer working with full stacks because they get the "big picture" more often. This does translate to a smoother development flow most of the time.

Team size/xp: yes. I work with 2 other full stacks, and then we have some dedicated data engineers, a dedicated FE, and a dedicated data analyst.

Increase/decrease in quality: almost certainly there is a decrease on the FE side because full stacks are thinking about everything. Oftentimes the FE will get "good enough" and we'll move on. I've seen dedicated FE people put a lot more care and attention than I would. However, for the BE I haven't noticed any decrease in quality vs a dedicated BE.

Actually to address the FE quality issue we've arrived at a process whereby the FS builds the full experience and gets it looking mostly good and completely functional, then we pass it off to our dedicated FE person to polish. The polish involves making things look better, responsive, accessible, and ensure legibility. These are things I could do as a FS, but I prefer to lean on the dedicated FE person so I can move onto other things. It's a system that works really well tbh because the FE person doesn't have to start from scratch or think about the programming as much, and the FS can still get the FE development done without time sinking the nitty gritty. It's a win-win.

Increase/decrease in product cohesion: full stacks intrinsically keep the stack cohesive, and that to me is part of the main benefit (see earlier statement regarding the architect role). This translates to the product as features are developed. Often we get a more maintainable system than if a BE and FE got together to agree on an API interface, both may be making concessions to the other that a full stack could work through in their own head and sort out quickly and more effectively.