Earlier quoted context omitted.
They're a pervasive indicator of performative security that intersects with serious practice in very few places. By a wide margin, their most impactful designed purpose is to sell security products and services.
Problem for companies is clients will ask for this or that certification (a due diligence checkbox they have little control over). Also unless you’re a big co., there is no way a service provider will let small co. customer interview the security and development teams and let you audit their security practices, etc. So at that point a known low bar is better than an unknown unset bar.
1. They should adopt frameworks only when there's certainty that the revenue coming in from the sales they enable justifies the expense of performing the framework.
2. They should minimize the scope of work they do to satisfy the framework, keeping a clear head about the fact that these are sales enablement tasks, not security program tasks.
3. They should design and execute a real security program independent of the frameworks, being careful not to let the real program get led around by the framework compliance tasks, which are unrelated to security.
The real danger with these frameworks is that people don't do (3), but rather use the framework as a runbook for building a security practice. That's a terrible idea with a terrible track record, because frameworks aren't designed to security your company, but rather to document what a consortium of IT security people, largely from huge companies with diffuse, unaccountable security teams, happen to be doing.