This has limited utility in practice because the data models reflect the underlying implementation and architectural details, particularly in the kinds of scalable systems big companies have. Specific tradeoffs are made in data models that reflect the tools available to the designer that might not apply to your environment. Moving data models between two systems that were not designed together can create a several order of magnitude difference in performance, cost, etc in using that data model.

It is a common problem for data model migration, even outside the context of the big tech companies. I've had cases where the systems were effectively not replicable even though the data was made available because the source system relied on some bespoke piece of data infrastructure software that no one else was likely to replicate. (Even hypothetically open sourcing this infrastructure isn't that helpful because it is usually extremely specific to the operational environment for which it was designed -- you can't drop it into your operational environment.)

All of which adds so much asymmetric friction and cost, which the source provider does not incur, that merely making data models exportable tends to generate limited user value in data models that inherently encode network effects.

The GDPR pretty much requires that already. You need to be able to export your data and another service must be able to parse them automatically, if reasonably possible.