This is a great question as it is not an uncommon concern.
What are metrics? A way to measure something. Of course they need to be valuable; if not, stop collecting them. If metrics are the basis of team decisions, then there is an opportunity for improvement. That is a red flag that priorities are not where they need to be for the business and/or the team. Remember the manifesto: "Working software is the primary measure of progress."
What is a Sprint? A time-boxed event to create focus and limit risk. If new work is being interjected (or even considered for injection) especially regularly, then there are concerns. How does the Development Team focus on the forecast and Sprint Goal from the Sprint Planning event? How does that affect risk?
What does The Scrum Guide say about modifying the Sprint Backlog during the Sprint?
- No changes are made that would endanger the Sprint Goal
- Quality goals do not decrease
- Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned
Ideally, once the Product Backlog is set at Sprint Planning, items should only be added or removed if they pertain to the Sprint Goal and do not affect the quality of the Increment.
If something is truly that critical that it warrants changing the plan, then there are factors to be considered.
- Has the item been refined and is it understood? Can work being immediately?
- How does inclusion affect the current items? Are in progress items abandoned or completed with not yet started items being dropped?
- Is there time and are there resources in the Sprint to complete the new item?
- What is the effect of not including it?
- What is the impact on the Development Team and Scrum Team? It is very disruptive to break (especially frequently) the Scrum framework pattern of events.
Since each Sprint is less than one month in length, there is generally not a high loss of value for making it the highest item on the Product Backlog for inclusion in the next Sprint. Perhaps there is more refinement needed in order for it to be Ready, so be sure to factor that into adjusting the current Sprint.
The Product Owner is the only one who can cancel a Sprint. The Scrum Team is to be self-organizing, so have a conversation. Understand all of the risks to both the current Sprint items and the new item. Disruptions affect the product and the individuals. (see "Agile processes promote sustainable development.")
More generally, regarding the post title: Improvement (product, learning, processes) is more important than metrics.