We want 6a + 10b. The move is NOT to solve for a and b (neither statement can, each is one equation in two unknowns); it is to ask whether the asked combination (6, 10) is a scalar multiple of the statement's combination, because if it is, the value is locked even though the prices are not.
Statement (1): 9a + 15b = 42. Is (6, 10) a multiple of (9, 15)? Reduce (9, 15) by 3 to (3, 5); reduce (6, 10) by 2 to (3, 5). same direction, so (6, 10) = 2 × (3, 5) = (2/3) × (9, 15). thus 6a + 10b = (2/3)(9a + 15b) = (2/3)(42) = 28. the prices are never needed. sufficient.
Statement (2): 15a + 25b = 70. Reduce (15, 25) by 5 to (3, 5), again the (3, 5) direction. so 6a + 10b = (2/5)(15a + 25b) = (2/5)(70) = 28. sufficient.
both statements describe the same line through the origin in (a, b)-space (all are multiples of 3a + 5b), and the asked quantity is another multiple of it, so each alone fixes 6a + 10b at 28; combining adds nothing.
the 'can't solve for a and b separately' trap, solvers see one equation in two unknowns and declare it insufficient, choosing (E) or (C), without testing whether the asked vector lies along the statement's vector. the multiplier is 2/3 (and 2/5), not a clean 2, so a solver who only checks for an integer multiple misses the match. choosing (C) assumes both are needed; each alone settles it. choosing (A)/(B) misses that the other statement carries the same line.