It is clear to me that some people think an agile approach means you can willy-nilly delete things in the process. This is also true for conventional project, but I do not think for the same reasons. For conventional projects, it seems time pressures cause elimination of certain functions or processes to keep the schedule. For agile, again no study but based on observed discussions, the elimination seems to be because there is no doctrine or perceived process that is required to be adhered.  This means things can be arbitrarily altered or changed, or even eliminated. That is certainly true, but you must consider the consequences of not performing the activity (for example product demonstration)?  From my perspective, there is a balance between adherence to a process (repeatable and baseline for learning  ) and adapting to the circumstances.

What does this product demonstration do, can I eliminate it, and what will likely be the consequences?

For the record, I am not in favor of the above approach of eliminating the product demonstration. I cannot think of a scenario in which that would or could be the best approach, and believe the merits of performing are too high.

1. confirm delivering the sprint objectives
2. engage the product owner by evoking feedback on the design instantiation
3. refine requirements for future work
4. learn (brainstorm) more about the product with the product owner
5. provide energy and a sense of progress and accomplishment
6. demonstrate success

There are many ways for us to do the work and it is best to respond to the conditions on the ground.  Understand the reasons for doing something, and if you do not know why some process is part of your project or product development process, think about what goal that process or step is designed to accomplish.  Perhaps ask other team members. If you do not know why, that does not necessarily mean it should be deleted.  To understand more about processes and associated costs, check out our book on reducing costs.