In this case, I imagine that CircleCI's controls involved developer workstations having anti-malware software, logs and audit trails for access to production systems, and some kind of intrusion detection system around those, and some SLAs and policies on how they react to alerts from those systems. It sounds like they had all of those things in place but the malware wasn't detected and their IDS didn't pick up the external access. Unfortunate, but both of those are entirely possible in many environments. SOC2 can't guarantee that your anti-malware systems or IDS are flawless and can't be bypassed by a clever attacker. Otherwise, since they've been able to identify what the attackers gained access to, it sounds like they did have logs and audit trails in place.
SOC2 auditors typically only have a limited understanding of security and technology themselves (the higher end ones might have more resources available to them) and are only able to sample a small amount of data during the observation window.
If you're trusting your sensitive data and credentials to a 3rd party, you should definitely require that they have SOC2 or better, but you still have to own your own security and consider how you need to protect yourself if/when they are compromised.
The method of attack sounds like CircleCI's production cloud (probably AWS) was impacted - "the targeted employee had privileges to generate production access tokens as part of the employee’s regular duties, the unauthorized third party was able to access and exfiltrate data from a subset of databases and stores, including customer environment variables, tokens, and keys."
But I am surprised that their SOC2 auditors didn't raise exceptions about their lack of controls. Sounds like a pretty immature program, they only talk about 2FA, MDM and SSO which is basic stuff. Where is the SIEM? Or CSPM? Or any alerting!? Yes there are SOC2 automation platforms out there that rubber stamp stuff, but at CircleCI's scale I'd expect more scrutiny.