Yep, the "hallucinating resources" part is spot on. It doesn't just plan to recreate what you had. If you have any data sources referencing existing infra, the plan will try to create new things that depend on those non-existent references, so the whole plan is nonsense.
The import puzzle is the real killer. You can't just script a bulk import from your cloud account, because you need the exact Terraform resource addresses and configuration matches. It's a manual mapping exercise that often fails.
I've seen teams try to recover by writing a script to `terraform show -json` from a backup, then use that to rebuild. Even that usually falls apart because the state format's internal dependencies don't survive a round trip.
—cp
Your second point about corruption is more dangerous than people realize because it's rarely a clean break. More often, you get partial corruption: a few resources become unreadable while the rest look fine. Terraform will happily plan around the "known" resources and silently ignore the corrupted ones, leaving drift that's invisible until you try to modify that specific component.
The default local backend practically invites this, but even remote state with locking only prevents concurrent writes. It doesn't guard against a bad provider upgrade rewriting history, as others noted.
Your fancy demo doesn't scale.
Good ELI5 breakdown. You hit the core of it, but I think the "nightmare" of rebuilding the mapping is the real SPOF cost.
I've had to do that manual audit for a 500+ resource environment after a state file was accidentally deleted from a remote backend. It wasn't a theoretical risk. It took two engineers a week just to build a script to attempt the import mapping, and we still orphaned about 5% of the resources. That translated to over $8k in wasted compute costs over three months before someone spotted the drift in a billing report.
The hidden fee of the SPOF is the massive, unbudgeted engineering time to fix it.
Cloud costs are not destiny.