None of that actually discredits your suggestions though; you could be right.
As a counter example, some people are PoC||GTFO types who wouldn't take offense easily but would rather punch holes in your argument. Seems like you might be jumping in with the advice before you know if it's that kind of environment.
Yes I've seen this a lot. The whizzy front end stuff in the demo is irrelevant.
Often, that is completely fine since the people doing those tasks can get their own tools and make things work.
Where it becomes hellish is when a large swath of users who are not able to self-service are given enterprise software which does not support the task they have to do, and then IT has to find a tool for them all to use, and then IT has to integrate that into the enterprise solution. It can get really messy.
This is something that I've seen constantly from the PMP/offering manager/product manager types and have been in the room where it happens. The thing that is utterly baffling is that it's usually a vague intent from an interested but not current user but then the person writing down these imagined requirements asks zero follow-up questions in a complete disservice to the user. So for example 'does your product use AI' or 'do you have a slack integration' open ended questions turn into firm requirements 'to close the deal' internally but with a completely headless goal. When I am usually in the room I at least give the customer the dignity of trying to work out what their idea/perceived benefit is with them so I can accurately transmit the knowledge to the team. Often someone more experienced with the product's offering can solve the real customer use case with existing features that just doesn't have the same label.
My favourite firing of a software company was when they expressed that they were refocusing from clear stability initiatives to machine learning driven analytic dashboards. This was even though this was a customer retention meeting company to company that was spawned over threats to not renew... because of stability issues.
My company is having trouble with this right now, in that we built a tool for the users with some higher level features managers would like, but it's still 3 ranks below the person purchasing the software. Even pitching it as a cost savings, they reply with "oh, my teams don't have trouble with that so we're not wasting money on it" then someone lower usually cuts in and says "well, we've been having trouble with it recently..."
Before I meet, I try to think of ways their product could be provide benefit including non-obvious ones. So I ask if their product does this or that, and why I think it could be useful.
Some companies tell me: it is on the road map, or why they think the feature will never be used, or an explanation of why it is extraordinarily difficult to implement. Cool. You probably know what you are talking about and I learned something interesting (to me anyway).
Other companies take it as a feature demand. I find this bizarre, because I have barely (or never) used their product. Some almost seem insulted that limitations in their product are being raised. Not my intention, and that raises a huge red flag, for "The lady doth protest too much, methinks"
I also hate demos of enterprise solutions. The feature details never matter to the financial buyer. What actually affects the financial buyer are product implementation delays caused by a major problem such as resiliency functionality or interoperability. Extending the timeline affects other projects, the budget, and the pushes out the timeline for the benefit to be realized. Edge cases and niche features don't, the business will usually sign off on production with an agreement that these issues will be resolved by the vendor. Rarely do the big problems arise in demos, but the small manageable ones do. The technical buyer is thrilled that their pet requirements are met, and the financial buyer is furious that their programme was a failure.
My 2 cents.