We've been using GDrive in one form or another since 2014 when they released Google Drive for Work. Primary use case nowadays for my team is an old legacy tool(been in place since 2014) that connects to our ERP and other internal tools to generate reports and export data with combined metadata from multiple tools/sources. Then if needed, makes a copy to different share drives and teams, assigns access rights for internal and external users. We have custom web front ends that allow them to interact with these exports along with fat clients if they need to manipulate a larger dataset of files.
My last check had the service account that I'm responsible for somewhere around 8.7 Million files with an average size around 9.2MB.
We have multiple of these "accounts", with similar use-cases across other teams. This is excluding the normal use of Gdrive with normal "rank-and-file" office works managing standard office docs.
We've felt the squeeze from google over the past few years, so we've already started migrating off of google services about 2.5 years into a 4 year project.
Yeah this doesn't seem to be in line with the expected use or target market of Drive. It sounds like your tool is probably creating all the files acting as one service account, and therefore hitting the limit if it is indeed per user.
I think the rule of thumb I would use is that if you're creating the files in an automated way, and then accessing them outside of Drive interfaces, in all cases, then it's probably a better fit for a web app with cloud storage backend. Google Cloud Storage or S3 would work well for this.