Dimensional Modeling of a Loan Approval Process and Fact Grain(s)
Dimensions that are 1-1 with facts are not unheard of. The problem with such dimensions is their size, which won't get any smaller just because you introduce a fact table that's even more detailed. Whether you truly need a dimension at the grain of an individual opportunity is a question I'd think about.

You don't mention measures in your question at all, and they're rather important for identifying the fact tables. For instance I'd expect the "Opportunity" (though I'm accustomed to calling it a Loan application) to have the amounts requested and approved. How would you calculate the total amount approved and the number of applications approved/total in the model you're thinking of?

I find it weird that you're attemting to convince the potential users that they need more functionality than they think they do; in my experience it's usually the other way around. How much domain experience do you have? If you're sure the use-cases you've come up with are real, you should be able to find a stakeholder who agrees with you. If you can't, you probably should postpone implementation until someone needs it.

(Unless your architecture is such that adding a more detailed fact table will require unreasonably large effort if not done upfront, e.g. you're planning to ETL source data directly to the dimensional data mart, throwing away all the data that doesn't fit  - but that's an argument against that architecture, not against the "Opportunity" fact table, IMO.)

An "accumulating snapshot" fact table is commonly mentioned when modelling a process in a dimensional paradigm (1, 2).