You make a good point, but it is totally unrealistic. Let me demonstrate where it will fail:
A more realistic approach is to get the best requirements you can, and build enough time into the project to handle 1.5-2 years worth of scope creep because that's what's going to happen with any huge system.
If you overbid by 1.5-2 years, you are sure to be outbid by a competitor who will stick to the "rigid requirements" method. So you will never receive a contract in the first place.
If you try to hardline your users by forcing them into a corner with rigid up front requirements that they cannot possibly help you formulate, they'll simply go outside the company and work with someone who knows how to run a project better and you'll get laid off.
Yes, but if you let the schedule slip those very same users will suddenly remember that you have a contract and force you into a corner with rigid contract stipulations about deadlines. If you want to avoid that, you'd better act first.
Don't forget, "the users" is not a single homogenous group, they are a collection of individuals, each with their own ideas and agenda, about half of which will hate your guts on principle (you mess with their computer, their routine, and their certainty about the future for no good reason they can think of). If you listen to them, they will tug you into a hundred different directions, roughly half of which are on the wrong side of a tall cliff.
I've been doing this for 20 years and I've seen the approach you are talking about fail over and over even with PM's that have 30 years experience. They knew better but corporate policy forced them to operate this way.
They just know that rigid requirements don't work. But do they have an actual alternative? You've apparently chosen to work on failing projects for the last 20 years, that tells me something about how difficult it is to find a project that's managed differently.
Inevitably the requirements were hopelessly incomplete and the users were pissed off when they had to sign off the project as complete because of what they agreed to, and in the end, the product did not meet their needs. The whole idea is to give the users the product they need. So even if you succeed in beating them on paper, and they are forced to sign off complete, you've failed.
Actually, the whole idea is to make money building something to specification. That is (apparently) what you were hired to do. If you don't like it, set up your own company, make your own rules, and fail to get _any_ customers because you are consequently overbidding and customers cannot tell the difference between you and the huge number of penny-pinching nitwits that define the rest of the industry.
Know what happens when you do this to your users? They hire contractors, who will be more flexible and give them what they want, and fire you.
Contractors will either work on a fixed budget, in which case they will either demand fixed requirements or stop working once the budget has run out, or they will work on time and materials basis, in which case they will be happy sitting on your premises and drinking coffee (and the occasional bit of programming) until the sun goes out.
You are better off with a "Look this is a big system and it's going to take a while to get it right. Lets figure out what you think you need now, we'll build it, and use that as a starting point to flesh out your system."
And you really claim to have 20 years of experience? First of all, a lowly peon will never get to sit down with the people who make the decisions and have this sort of talk with them. If you somehow managed to do it anyway, they will smile and say that they cannot budget for an open-ended development project (which is what you are proposing), so they are just going to go with a fixed set of requirements and the associated fixed budget.
XP for the win for corporate development, Waterfall = FAIL. Waterfall can only succeed if you are a software company building a boxed static product produced by someone that knows what they want.
XP = lack of organisation = lack of milestones = lack of deadlines = lack of ability to budget = fail.
At the end of the day a large corporate software project will take 10x longer than you think it will. I've never seen one that didn't. I've seen plenty that failed. Plan accordingly.
You essentially propose to do software development on a time and materials basis. Good luck finding any customers that will write you a blank cheque like that...