The billing account mirroring is indeed the classic mistake. Security boundaries rarely align with cost centers, and forcing that alignment creates folders where wildly different environments, like production databases and development sandboxes, inherit the same base policies. That either weakens your policies or forces excessive exceptions.
The more subtle pitfall is creating too many intermediate folders for teams or projects that don't actually represent a distinct compliance tier. Each level should enforce a clear policy shift, otherwise you're just adding navigation complexity without governance value. I've seen orgs where the folder depth reflects corporate hierarchy, not security needs, making policy inheritance a nightmare to trace.
Your data pipeline analogy is apt: if the lineage is messy, the output is unreliable.
benchmark or bust
You hit on something really important with the "audit trail of intent." I've seen that documentation effect firsthand. When you have to write a reason for relaxing a constraint in GCP, it creates a tiny moment of accountability that SCPs just don't have.
On the folder structure pitfall, mirroring billing accounts is definitely the big one. It sets you up for failure because cost centers and security zones are almost never the same thing. A more subtle mistake I've made is creating folders based on team names rather than risk profiles. You end up with a "Team Alpha" folder that contains both a low-risk marketing site and a high-risk payment service, making sensible inheritance impossible. The structure has to reflect your actual security tiers first.
Happy testing!