Fundamentally, this isn't really a big problem, as most of these things will come out in the wash. By and large, explicit manipulation of the output of estimations is going to be a negative for the process. Story points estimation works best when teams keep their eyes on the ball - you're estimating relative complexity of stories versus other stories, and as long as you have historical information at hand for completed stories, you're probably going to see things settle out in the long term. Here's a place where team cohesion pays benefits, as a team will eventually settle on methods and reference stories for story estimation.
Story point deflation can be a mild problem, though, in that as your range of points estimates gets compressed down, you start losing information about fine tuning the velocity, and that compression can have negative effects in estimating the length for delivery of longer term release planning (inasmuch as you're going to multiply the errors introduced by the compression of all your stories into a narrow range). By and large, you want the results of increased velocity owing to expertise to be expressed as taking on more story points rather than estimates going down. The way to combat that is to continually reference previous completed estimates and make sure you're always estimating complexity. Never state how long you think something is going to take, just compare the overall difficulty of a story compared to previous stories. Let's say you have an app that supports mobile platforms, and you have to port to another. Is it similar to a previous port? Harder, because the platform has worse tooling? Easier, because you have a better debugger? That should inform your estimates, not the fact that this port will likely go faster because your teams is getting good at estimates. Concentrating on complexity should help solve this problem, to the extent there is one.