OK, this may be many things:
The simplest explanation in your case is a som misconfiguration with that timer you are using to trigger the pollings. I would need to know how you are using this, is it triggering an interrupt where you set a flag to trigger the accelerometer polling? are you polling the timer manually to trigger the accelerometer polling. In any case, toggling an output pin high and low when that happens and seeing it with the oscilloscope will give you valuable information. Are all polling periods longer, or are there just some of them that are taking much more than expected?
The one that I have seen more often is a slow I2C handling routines. Your I2C might be set up at 400KHz, and that is indeed the speed at which the bits of a byte are read and written, but there is some processing time between bytes that depends very heavily on your code complexity. In your case, since you are using multiple byte read mode, this time isn't actually between bytes, but between polling cycles. But it is strange that this would be your problem, it's not such a frequent polling nor large data reads.
What I would do in your case (having some sort of measurement equipment, which you seem to have), is to check that all the timings are as you expect. Don't assume anything, measure it and verify that it is doing what you expect. In this regard, I would start with the easiest things. Is the clock running at 400kHz? Are the six bytes being read without delays between them? Are there the expected idle gaps between pollings? Is the I2C bus getting stuck (SDA and/or SCL low for long period of time) between pollings? are there any unexpected communications or activity on the bus apart from the ones with the accelerometer? These are some of the things that I would check to get a clue of what might be going wrong. The golden rule here is Don't speculate, measure it!
If everything above is perfect and as expected, just with a longer time period between pollings in a stable manner. I would start checking the timing of the sofware to get an idea of how much time is going in each routine, I have seen many software developers surprised by how much time some apparently simple operations can take. To do this, use the output pin bit toggling described in the first bullet point. Use a couple of IO ports, so you have two markers one on each channel of the scope, and change the place on the code where you toggle those bits, just play with it to check for any slow parts of the code. If you want another golden rule for this, divide and conquer. Set your markers at the highest abstraction routines, and dig lower dividing the slow part of code until you find what's wrong.
Try this, and let me know if it helped.
Cheers, and good luck!