I am curious why anyone would calculate this or care.  Is there a use for this information?

Wow this is intense. I'll defer to the engineers here :)

Well I am actually developing a little app in c++ and I have a need for this information, and of course i'd like it to be as accurate as possible.

drewfx1
I think you're overthinking it.
7 samples < 1 tick, so I'm guessing what you're seeing is just because it's rounded to the nearest tick.

 
..and twice rounded off, since change of tempo as well as at the end.
 
You won't change tempo in the middle of a quarternote.

Okay, being something of a math geek, I had to play around with this a little. I initially thought I had it on the run as a rounding error due to the binary representation of decimal fractions, but couldn't quite make it work out. At some tempos, I could predict the exact error in what SONAR would show out at measure 1055, for example, but I actually couldn't make sense of the example you gave where 140BPM is 19.6875 samples/tick or a nice even 18900 samples/beat.
 
Nevertheless, I think this is either a function of their not having allocated a enough precision to represent these fractional samples/tick values or they're using some internal reference for time other than sample rate that doesn't resolve evenly into both samples and ticks.
 
In any case, this is an interesting discrepancy but definitely not worth worrying about in the real world.

good one.  x2 shows (in the inspector) 7229089 x3 gives me 7229092. cubase 7 and studio one give me 7229095.  Reason 7 gives me 7229096.  
on second try took x3 and got the same 7229088 as you.  even exporting and opening in wavosaur yielded the same numbers.

I know Pi to 40 decimal places (really) and even I'm not going to touch this subject.

As we can see different applications give slightly different results, but all of the differences are in the order of ppm (parts per million). There are two main sources of error : pc clock and computational errors. Since it is not practical to try to control the pc clock's error (it is the smallest by the way in this case, ppb), just control the computational errors by using double precision variables and careful rounding. Then just live happy to see differences that are more linked to programmers computational methods. 

Seems strange, and I wonder if it causes "problems" with sound coherence. A few samples isn't much but when you're stacking frequencies and trying to phase align bass parts etc, it could come in to play. Cubase, Studio One and Reason all seem "a lot" closer to the "correct" calculation. I'd be interested to see what the engineers have to say about it. 64-bit double precision engine doesn't really help much if your sample timing accuracy is off.

Samples must be the same regardless of the software being used, assuming that raw data is the same. Therefore, no sound differences should be present if playback is done following every single data point. On the other hand, how the different applications load the raw data might also be a difference (considering the start and ending bits, data stacks, etc.). Data transformation to other variables will depend on calculation method, data precision, and rounding procedures. Since errors are in the parts per million order of magnitude it is definitely not a big deal. Our ears and brain will not catch them up.
In addition, there are ways to synchronize the bars with external triggers to maintain the timing accuracy at its best, these techniques also minimize long time errors.