Restart copy vs cloud object lock
Object lock is the most common answer to the immutable-copy requirement, and it is a good tool. The comparison is not about good and bad. It is about what each one survives.
What cloud object lock survives
Accidental deletion. A rogue script. Most ransomware that never obtains cloud credentials. Compliance-mode object lock with a sane retention window is real protection, and for many datasets it is enough.
What it depends on
Identity. The lock is enforced by the provider's control plane, and the control plane obeys credentials. Crews harvest cloud and domain credentials for weeks before striking; accounts get phished, tokens get stolen, and misconfigured retention gets shortened quietly. There is also the day-after problem: restoring tens of terabytes over a wire during an incident is measured in days and egress fees, not hours.
What a restart copy survives
Everything that arrives over a wire, because nothing arrives over a wire. No standing connection, no credential from your world, immutability enforced by the hardware. The trade: it holds your critical core, not your entire estate, and it sits in your building where you can point at it. During an incident that last part matters more than it sounds; restoration starts immediately, at local speed, run by whoever is on shift.
The honest architecture
Use both. Object lock for breadth across the full estate. A physically isolated restart copy for the core you restart the business from. The five-question test tells you whether your current setup covers the second part.