Mid-sprint demos are not part of the Scrum framework, and are likely an X/Y solution for some unarticulated process problem. Instead, you should ask:
What problem are we trying to solve with mid-sprint demos?
If neither the stakeholders nor the Scrum Team can readily identify the underlying problem, I've listed quite a few common issues that might lead teams into applying this kind of Scrum anti-pattern.
Mid-Sprint Demos: An Anti-Pattern
Mid-sprint demos are an anti-pattern. The Scrum Guide says (emphasis mine):
A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed.
Soliciting feedback about a half-finished increment makes no sense, especially since many full-stack features—or vertical slices of value/functionality, if you prefer—rely on other stories that may not yet be done within the current Sprint. In addition, such a demo would be unable to meaningfully demonstrate the completion or value of a Sprint Goal.
Mid-Sprint Demos: A Poor Solution for Process Problems
A mid-sprint demo is a "project smell," generally indicating that the organization is trying to use the additional demos as a stand-in for more comprehensive project controls. Some reasons that companies might make this mistake include:
Sprints that are too long.
Consider shortening your Sprint length to one or two weeks to enable a tighter feedback loop. Shorter iterations provide stakeholders with more opportunities to inspect the process and iteratively refine the product, but at the cost of higher framework overhead.
Sprints that consistently deliver the wrong thing.
Consider working more closely with stakeholders during story writing, or during the development of acceptance testing criteria for each vertical slice of functionality. Remember that user stories aren't specifications; they're placeholders for conversations with a story's value consumers!
A lack of trust between the stakeholders and the Scrum team.
Consider increasing the level of engagement between the Product Owner and the Development Team during Sprint Planning. Also consider increasing the level of engagement between the stakeholders and the Scrum Team during story-writing and Backlog Refinement. Perhaps most important of all, consider reducing the number of stories accepted into each Sprint until the Scrum Team can reliably deliver on its commitments!
Lack of stakeholder participation in Sprint Reviews and Backlog Refinement.
Stakeholders should always participate in Sprint Reviews, and in extra-framework discussions with the Product Owner about the contents of the Product Backlog. The Product Owner should follow every Sprint Review with some refinement of the Product Backlog that reflects the reactions and feedback provided by the stakeholders.
Poorly-specified requirements, or unclear value propositions.
User stories that don't adequately specify who who must benefit from the story, or that aren't granular enough to properly identify the value a completed story should provide, will often lead to building the wrong thing. Consider refining or decomposing your user stories better.
Not writing the acceptance criteria first.
This is closely related to "building the wrong thing." Agile processes often work best when everyone agrees on a goal. Consider making the creation of testable acceptance criteria (such as customer-facing Cucumber tests, for example) as part of your "definition of done" for each story. Make sure that you work with the stakeholders to write the tests before you start working on the feature in order to make sure that everyone agrees on what the "right thing" should do when it's finished.
NB: Don't forget to factor the additional time and effort required to write and execute user acceptance tests into your story estimates!
There can certainly be other reasons, too. Your best bet is to ask. "What problem are we trying to solve with mid-sprint demos?" is not only a reasonable question, but it can immediately improve communication and help the Scrum Team and the organization address the real issues head-on.