BPM shouldn't be used... it's a set parameter of the map like OD, DR, CS, and AR. It has a specific value and it's already displayed in a clear way for people that want to know it. What you want is a measure of EBPM (Effective BPM)... because things like significance of BPM changes (ie how important is the range of BPM displayed) and what baseline the map is mapped to (ie 1/2 beats vs 1/4 beats) are the things that are currently hidden, but can be calculated.
As for how to measure EBPM, well, it's essentially the baseline object density of a map. Objects/second is one measure of that. Also interesting are the peak burst rates (ie the streamy bits) and the lengths of bursts (because the occasional triple isn't a stream). Movement rate is the same... a baseline average velocity (the "air speed" of the map... a measure of the size of the beat spacing), the peak burst rates (how extreme jumps are) and the lengths of those bursts (how long the jump sequences are). These are the things I would be focusing on, and recall that Tom was working on, and had a pretty good grasp of what was needed to extract meaningful numbers (which is why I've never felt the need to play with things personally further). They're also the exact things that you want on a star graph... things like set parameters should just be listed. Derived stats from the mapping are the only things that need be on a star map, and Tom seemed to have a good handle on those, so I'd go with his stuff (although I haven't seriously looked at his stuff, just read the post a while back, I remember it to be fairly solid, and people seem to like the numbers he's producing). If peak burst rates and lengths are combined that gives four stats: an EBPM measure, streaminess, average velocity, and jumpiness.
This leaves room for say some sort of measure of chaos... ie the jerkiness of the map, jerk technically being changes in acceleration, but in this case it could probably be derived somehow from the amount and size of changes in adjacent intervals between objects.
Average queue length would be another possible derived stat that could be used. However, that depends on if AR remains not a preference, and it's also going to be correlated to both AR and the measures of object density (both the average and the burstiness), in a way that might be easily enough judged (assuming that the object density is available on the star graph and the AR is listed elsewhere). So it could probably be left out to keep the map simple (it also has the problem of interpretation... both ends are hard in their own way).
That leaves five stats: two for streams, two for jumps, and one to represent rhythm/flow chaos. Which seems a good mix to me for giving a feeling about what the map itself might be like (as opposed to just the parameters it will be played under).