It sounds like the issue you're running into has more to do with how the Catalog Items are set up rather than the Survey part itself. You could probably solve it by adding something custom to surveys, but really the best answer is probably just to set the fields for the catalog item.
My recommendation would be to add a block to the Catalog Item workflow that sets the Assignment Group as you'd expect. To handle a single survey per request, you'd want to make sure the Survey is sent out based on the Request rather than the Requested Item, but as you said, sometimes that means multiple groups are fulfilling the actual requested items. If you decided to go that route, then my suggestion would be to either select a "most responsible" to tie the survey to, or else build a catch-all group for those requests where you really can't narrow it down. When you're trying to troubleshoot issues, if it at least lands CLOSE to the responsible group, then you won't have to dig quite so far to find the actual group responsible.
Alternative #2 provides a little more clarity - if you generate the survey from the Requested Items, you potentially have multiple surveys going out per order, that's true, but depending on how you're set up, most Catalog Requests will generate a single ReqItem for a Req, so not a huge concern. On the cases where someone wants to do a full setup, request a laptop, office, email address all in one order, having a survey for each component might shed some better light on things than having one overall group.
The more detail you have, the better your reporting will look, but for investigation purposes, if on the survey if I say I had a bad experience because x, y, or z, it should still not be too difficult to figure out the team responsible for that particular part of the process. It's just the initial graph of Good or Bad results by Assignment group.
A note on breakdown by Assigned To. Remember the way that Breakdowns work is by working from a list of all possible values, and it will separately consider each possibility. In newer versions of now the property that governs it is raised to 10k possible breakdown values, but this still can be a hassle if you're not careful, particularly if you're collecting a breakdown matrix. So it's definitely POSSIBLE to breakdown by Assigned To, just don't think "I'll set my Breakdown Source to the User table and that's good enough." A lot of times the User table has too many people, and it just won't work. But realistically not just any user can be assigned to an Incident or Request, so limit it appropriately. At the very least, instead of using Sys_id from the User table, use the User field from the Sys_User_has_role table where the role is ITIL. So at least you're getting the subset of fulfillers. Ideally you want the result set as small as possible so that you're not searching through the 12 Josh Cooper's that are end users working on location to get to the one Josh Cooper who actually resolves Incidents and fulfills Requests. Just a tip!
