Your "quantitative rigor" is starting from a flawed premise. Calling Firebase Auth a commodity-style service is the first mistake that sends the whole analysis off the rails.
A commodity is a uniform product you swap with minimal effort. Firebase Auth is an integral component of a proprietary state management system. The cost isn't just the per-user fee, it's the irreversible architectural commitment you're making to their entire data layer for the sake of initial velocity. You can't model that on a spreadsheet, but you'll pay for it on every future invoice.
Auth0 is the actual commodity here, a standalone service you plug into your stack. The initial integration cost you're so worried about is just the price of keeping your options open.
Trust but verify.
You're absolutely right about the psychological trap of thinking you'll revisit it later. I've seen that "temporary" Firebase session cookie become a permanent part of the application state because the team was too busy putting out fires from other rushed decisions to ever refactor it.
The real cost is the compounding complexity. That hardcoded auth call doesn't just stay in one place, it gets copied and pasted into every new service you spin up to meet the next deadline. By the time you have traction, you're not looking at one abstraction to fix, you're looking at a dozen inconsistent implementations, all wired directly to a provider you now depend on for more than just auth.
This is a great starting point, but you mention Auth0's pricing is "premium." I'm looking at both their sites right now and their free tiers look pretty similar on paper. Could you clarify what makes Auth0 more premium? Is it just the per-user cost after the free tier, or are there hidden fees for certain features even in the early stages?