Let's take the simplest example of flat pricing for a logging service: You pay $X and you get all the service you can consume. A salesperson tries to intelligently set $X for you. We'll even spot the salesperson full knowledge of the previous year of usage, and we'll even stipulate that the purchasing company is 100% honest about their intent to consume, but that they do not have a 100% accurate prediction of the future.

The problem here is the statistical distribution of the usage will bankrupt you as a company if you try that. People mentally want to model everything as nice, polite distributions through a combination of all the statistics classes they've ever taken using them (where the "uniform" distribution is the default and "gaussian" is if you want to get fancy) and internal cognitive biases around the nice distributions generally encountered in most real life and a general lack of experience with pathological ones, but the real distribution of consumption is grotesquely pathological and has huge spikes in the tail. The probability of one of your 10 biggest customers, which collectively account for ~90% of your business, getting an unexpected 10x or greater spike, isn't negligible like a naive high school statistical analysis might suggest. It is instead virtually certain.

I've simplified this problem down just to concentrate on that bare statistical problem, which is something engineers should try to develop an intuition for. However, as we de-simplify the problem by re-introducing back all the real world complications, they all tend to make this problem even worse. For instance, give a company an all-they-can-eat deal, and if they accidentally spike your usage because the intern accidentally committed a debug logging message that spiked their usage by 50x, they have no particular incentive to fix that.

Naturally, in the real world you'd put limits in the contract... but if you think about it, flat pricing with limits that you can realistically hit because the limits really ought to be thought of in logarithmic terms, rather than linear ones, is just usage based billing with extra steps.

I've also taken advantage of the local topic of conversation being a logging service. Other businesses are not necessarily so pathologically distributed. Email is more reasonable to charge per seat, partially because people are used to the pathological part of the resource consumption distribution being cut off... or to put it in the terms everyone is used to, people are used to being told they can't attached a 3.5 terabyte attachment to their email and that emails to a few thousand people at a time generally cause trouble. Since the number of emails an account can use is bound to some degree by human attention and the size and therefore resource consumption of the email is bound by size limits, it tends to be less pathological. Email also permits throttling, and indeed, if someone is suddenly receiving millions of emails per hour they may be happy that you are throttling their inbox. Although in the end it's probably still more pathological than you may intuit.

Even here though, when you return the real world back into the picture it doesn't mean a flat pricing model perfectly works. Give them an $X/month all-you-can-eat, and one of your customers will find a way to provide email addresses to every resident in a country or something. Put limits on that and it's just usage with extra steps. There is a sense in which usage-based-billing is the only real option, it's just a matter of the details of how you price and market it.