If those people are great coders and "best of the best", then they'd be a tremendous asset to the remaining product team and the low-performing people from that team let go, to make room for the really excellent people from the dead product's team.
Management thinks "we need to make a quick hard decision and get moving."
To go through each person on the soon to be cut product line and determine their skill set, look at everyone's past evaluations, and then to cross train them on the new product and get them up to speed will take TIME and MONEY. It's quicker and easier to just cut them. Added bonus: we don't get into arguments about discrimination, who sucked up to which boss, etc.
Hypothetical (well, not really) situation. You've just taken over another company in an acquisition. The company had the same product line as an existing division, so you're going to combine them. The acquired company has 3/4ths more business. The existing division has a reputation of a team that Gets Things Done and Done Well. Existing division uses the same software and hardware as the rest of the company. New company uses different development architecture - I'm talking Java/Unix versus .NET/Windows. What do you standardize on? Who do you keep?
IT people start digging into the architecture and doing comparisons. Business people? They cut it short. They tell IT to stop doing that. The acquired company has more business. Ergo, it will cost more to convert their business to the existing division, so the decision is to standardize on the acquired company's systems. Don't care about the skills sets, the expertise, awards won, etc - we need to make a quick decision and get moving.
And if anyone is hiring, 10% of my group just got laid off (not me). And some of them are good. But they don't know the other system, and we have too many people...