I don't think SOC2 specifically demands SSO and just encourages it. Probably good, since such security mandates often age badly, even such a broad concept like SSO could fall victim. And there is always that one tool that isn't integrated, ironically inhouse software often neglects it.

But otherwise I believe you are very on point. Although from a developer perspective perhaps it should be segmented the other way around. If I can outsource to identity providers, I have delegated a lot of risk and work. And while the initial implementation might be a bit more cumbersome, in the long run it certainly is less development intensive than providing a complete user management interface. And maintenance for a few keys is easier than user management, even if you still have to do some of that.

Perhaps not using SSO should be marketed as some privacy focused benefit, which is more expensive.

It doesn't specifically demand it, but (1) SSO is the simplest way to knock out a huge swath of control objectives, and (2) once you attest to a control like SSO, it's extremely annoying to pull that back. If you hire security/compliance/engineering management to take you through SOC2 and they don't set up and attest to SSO, they're bad at their job.