My company has standardized the scrum process and tools throughout the company including things like the start and end date of each sprint so that all iterations for all scrum teams start and end at the same time. Although they don't always share the metrics with us, it is my understanding that management looks at various metrics that they collect. It seems to me that some metrics are reasonable and some are pretty crazy. I think that comparing team velocity across scrum teams doesn't make much sense since each team calibrates their points a little different. Of course, the company has some general guidelines for small, medium, and large stories (3, 5, and 8 points), but I don't think the sizing of stories can be standardized enough to make cross team comparisons useful. However, process metrics, such as the number of stories planned vs completed per sprint seem to make some sense to me. However, this seems to encourage us on the scrum teams to plan very conservatively. Since we know that management is looking at this, we do not commit to more that we are absolutely sure we can complete in each sprint. This results in us always completing our stories for the sprint early. We then start work on stuff for the next sprint or whatever we think is useful. Maybe that is the way it should work or is not?
In general, you're right about making comparisons across teams -- one team's point may not be the same as another team's point. If the point sizes are consistent across teams, which it sounds like it may be in your case, then maybe it's useful to compare across teams. What does management do with those metrics though? What they do with them also plays into whether or not the metrics tracking makes sense. If it's just to see if one team is more productive than another, then I would say that's not the way it should be. Teams are made up of people, not robots. Different people will have different rates of solving problems. Heck, depending on the prevailing situation, the same person may not even solve solve the same problem the same way every time. There are many variables, both internal and external, to the person/people working on the problem so using story points to measure productivity is not encouraged.
The advice that I pass on to teams is to care more about your point trends rather than the point totals. If you completed an average of 10 story points in the last three iterations and then only do 5 points in this iteration, then something might be going on that the team or the scrum master or product owner needs to address. Point estimate metrics should be used to help spot problems and make improvements.
Remember too that points are used for estimation and estimates are imprecise by nature. That's another red flag, when points start getting used as precise measures. Some teams even abandon story point estimation after a while because of the problems and chaos involved when people can't agree on how to use them properly. In fact, there's actually a growing push for #NoEstimates -- you just break stories up into manageable chunks and iterate.
The best ideas are the crazy ones. If you have a crazy idea and it works, it's really valuable.—Kent Beck