There are plenty of OOB entities that take a considerable amount of dataverse capacity which is pretty expensive. In my opinion those tables should count as file storage which is cheaper since it's not real customer data but out of the box customization data that is required for the platform to operate. For example, I have 3 development environments where the "LocalizedLabel" table is taking 2GB per environment, "Attribute" table is taking over 740MB, "Plugin assembly base" is taking 500MB, "System Form Base" is taking 425MB, "Report Base" is taking 300MB, "Dependency Node Base" and "Dependency Base" are taking 245MB each, etc. Roughly 6GB per environment are dedicated to basic OOB entities that store solution component details. Some other entities have already been moved to the file store like "Solution", "Async Operation", "Web Resource Base", so I believe it's only fair to move all such entities to the file store instead of only some.

I've had a client that was forced to overwrite the entire OOB entitlement logic in the past because async operation was taking 100GB of storage to store the entitlement expiration and activation triggers. They opted with writing a service to delete the OOB triggers and expire them when the date came as Microsoft's official response was that this was by design. Then, the async operation table moved to file storage. If it was file storage from the beginning, they probably would have paid the price instead of moving to a custom solution.