Cancelling Userstory => earn the storypoints anyway?

I suppose you could do it either way.  On one hand velocity is meant to track the work a team is able to accomplish. Partially completed work still takes man hours and effort, so those points are useful towards accurately predicting future sprints.  On the other hand, this could also be addressed during a retrospective by acknowledging that the sprint had a below-average velocity, discussing why, and then moving on.  This method is more useful for quickly noting and addressing problems.  And then I'm sure some teams will split the difference and give it half the story points because the work was "halfway done."

While I think I could justify it all three ways, my personal thoughts are to agree with you.  Tracking velocity as a measure of work a team is able to complete instead of work a team is able to do seems to me like a more valuable metric.  Incomplete work doesn't do anyone any favors.  That's a big part of agile, and why we do iterations with deliverable increments in the first place.

Story points aren't earned, there is no value in them. The value is in the delivered increment. The matter of concern is this: will the demonstrated Jira behavior give the team a false indication of how much work they think they can take on in the next Sprint?

I would cancel that story and replace it by another one with a similar number of points. 

I would just set it to obsolete and not take the story points.  It will bring your velocity down as I think it should.  If this was just a one time occurance then your velocity will go down and will gradually go back up.  If this scenario happens often then your velocity will go down and stay down.

Story Points are assigned for estimation and as the team progresses and the Definition of Done gets better so does their accuracy of story point estimation. There is no concept of earning a story point. It's main purpose is for the team to gauge their capacity each sprint so they can accurately estimate how much they can do the next sprint. It's a continuous feedback loop.

Whether you consume the story points in the current Sprint or not depends the updated estimate of your story.Lets assume you Story was originally estimated at 3 points

1) The estimate after the next planning is still 3. That means your team has either wrongly estimated the user story or faced impediments or did not correctly estimate for technical spike/research/analysis etc. that has to be updated in the previous sprint to accurately show case the lower velocity that the team actually achieved compared to the average. So you put a value of 0 to allow the system to tell you that you originally forecasted 40 of which you achieved only achieved 37 really!

2) The estimate after the next planning is 1. That means you have to update the previous sprint value with 2 as you have to accurately update the true velocity of the team. It's just that your original estimate of 3 points is distributed across two sprints but the team did manage to finish it as it estimated. In this case you team achieved 39 of the planned 40. That's what you want to record!

The goal is to measure how close the team's forecast is w.r.t velocity.