How to stop Mid-Sprint Story-Scope changes?

The whole point of a Sprint is to meet a Sprint Goal. It lends purpose to the selection of work they are doing and makes it coherent.

Do these scope changes help or hinder the ability of the Developers to meet the Sprint Goal commitment they have made?

Hi Ian, the Scope Goal(s) are often being modified by those who are changing the User Stories-Scope mid-Sprint too.  It should be noted that the Product Owner... is one of the Company Owners.

You don't mention the Sprint Goal at all. I'd start there, by establishing a Sprint Goal that the team believes is achievable within the Sprint. Then, instead of tracking quantity of work completed or velocity or anything else, start with observing if the team is able to achieve the Sprint Goal or not. Since the Sprint Goal is the commitment made by the Developers, it doesn't matter quite so much how much work you are completing or what the percentage of work changed between Sprint Planning and the end of the Sprint.

Once you start working with a coherent Sprint Goal, observe the team for a while. If the team is able to meet their Sprint Goal commitment Sprint-over-Sprint, then you're in a much better place than the current data may suggest. However, if the team is unable to meet their Sprint Goal commitment or if the work is changing so drastically that the Sprint Goal becomes invalidated, that would be a problem to address.

If this changing work does impact the Sprint Goal, then you need to dig a lot deeper into why the work is shifting. There are plenty of possible reasons and lots of things to do about it. However, addressing this can help increase the predictability of the team. It should be noted, though, that increasing predictability does not necessarily mean reducing the amount of work that changes. In highly volatile environments it could mean making the planned, committed step represented by the Sprint Goal into a very small step that consumes a small fraction of the team's capacity.

"However, my Product Owner and Dev Team Lead believe that "Agile" means you can change all User Stories in and out of a Sprint, during Mid-Sprint, on a "whim" basis. "

According to the Scrum Guide they can, as long as this change does not damage the Sprint goal.

Of course Scrum master can facilitate different discussions with both PO and Developers about this attitude, or use retrospective to address this issue, especially focusing on possible technical debt.

One thing which team SHOULD discuss on next retrospective is WHY do you(as Scrum master presumably) consider their changes to be "whim", and if it is actually a "whim" or some necessary change?

@Nicholas is correct.  The entire Sprint Backlog can be changed if it doesn't jeopardize the Sprint Goal. But if this happens frequently, as a Scrum Master I would want to understand why. It seems like an issue with the refinement and management of Product Backlog items. 

I can't analyze a Sprint's reports because of this, other than to say "the scope changed too much and for no good reasons". 

Velocity is meaningless because the Story Points metrics are all over the place, and our Sprint's run past their Release Date by 75%. 

Part of that statement is correct. I do not see anything in your explanation that makes me believe that there is not a good reason.  To be honest though, I don't know why you would want to analyze any kind of report based upon the number of items in the backlog or how long it took to complete them.  The real measure of success is whether at least one usable increment of product that provides value is created. The means of getting there is not of great concern for me. The velocity that people so want to be able to measure is how much value is delivered, not how many items or how fast they were finished.  Also, a release date in Scrum is whenever the most recent increment is delivered to the stakeholders, not a specific date set well in advance.  

As an Agile Coach, I'm sure that you are familiar with many practices that allow organizations to react quickly to changes.  From what you explained in your original post, it seems like this team has found a practice that works for them that allows those changes.  It also sounds more Kanban based than Scrum. If this is indeed delivering the value that the stakeholders want, why would you want to change it?  What is the driving factor for the change?

Velocity is meaningless because the Story Points metrics are all over the place,

I would be me if I didn't comment on this specifically.  Velocity calculated by Story Points are meaningless anyway.  Story Points are guesses made at a specific point in time based upon the information known at that specific point in time.  As soon as work begins, new information is obtained that could have caused the estimate to be different.  So as soon as work begins, the estimate is meaningless. Using Story Points to determine how fast things are done would be like trying to estimate when you can arrive in another city based upon how many boxes you can fit into the backseat of your automobile.  They have no correlation. You might want to read this article by Ron Jeffries who is said to have invented Story Points. It may help you better understand the history and significance of them. 

Very good points all around gentlemen.  Thank you.

@Russ: how does the team feel about this? (The "developers"?)