Tentative answer:
There may be some relaxation mechanism, the way a dent will appear in a carpet if you leave a chair leg sitting on it too long. This specification places an upper limit on the effect that will have on the reading.
So if you read 100N force after 1 second, the reading may have drifted by 5% or 5N (or less) after 10 seconds, 10N (or less) after 100 seconds, 15N after 1000 seconds and so on. (I am assuming they mean log(base 10) but the datasheet is not explicit on that point)
It's not obvious if there is a lower limit to this behaviour (i.e. 15% difference between 1ms and 1 second) but I would assume so, down to the 5 us specified settling time.
Another question is : does the same drift apply when you then remove the weight? (the chair leg depression disappears eventually after you move the chair). If I were contemplating this sensor the first thing I would do is get my hands on one and characterise it with actual measurements. It may be better than the spec, bearing in mind that future production may vary within these limits.
Whether this is good or bad depends on whether it meets your needs, and how well it compares with other sensor technologies within your budget.
@Olin Lathrop's answer is wrong. Unfortunately, I don't have the reputation to either downvote or comment on his answer. It's curious that he chose to claim that what is being achieved in the paper you link isn't physically possible...
As madgwick's paper demonstrates it is indeed possible to maintain stable orientation estimates over long durations using only a 9 DOF MEMS MARG. His algorithm was also benchmarked on a bunch of different hardware by Kris Winer. He, in particular, demonstrates virtually drift-free tracking over a half hour period with both time periods of lying still and being moved around. The relative error of the absolute orientation is less than a degree over this time period. Impressively this is achieved without resorting to a full Kalman filter and requires only scalar operations instead of needing the computationally expensive matrix inversion required by a Kalman filter.
Looking at it through the lens of observability the problem of orientation estimation is a problem with six coupled states. 3 states for the orientation itself and 3 states for the derivatives of the orientation (ie the angular rates)
Obviously, the gyroscopes allow for direct measurement of the latter three states. This leaves the issue of the three orientation states. Assuming that there is a static gravitational field and magnetic field that are not aligned, we can fix two of the three directions. The structure of the coordinate system imposes constraints on the relationship between the three directions allowing the third to be fixed simply by construction. As such the system is observable, which is to say no, unlike @Olin Lathrop's claim, the "physics" explicitly allows you to determine the complete orientation even without depending on any integration. As such his objection regarding integration error is completely unfounded.
With that being said integration is still a useful process as it allows sensor fusion to be performed which is to say that you are essentially performing a best fit between the implied angular rate incremental positions and the incremental directly measured absolute orientations. Seeing as these are likely not correlated in that they are measuring three completely separate physical phenomena they allow you to significantly improve the accuracy and robustness of your orientation estimation.
This brings us to the issue you raised regarding the origin of the lower frequency bound on the tracking accuracy. Not being the author of the algorithm and only ever having used it as a component in a bigger solution where its performance was adequate I haven't personally dug through every line of every equation in the paper but that being said the temporal nature of the problem does indeed point to something related to timesteps.
The numerical integration itself might contribute but is likely not the main driver as its performance should be reasonably robust against larger timesteps. I would look at the single step gradient descent (second paragraph on page 7 of the linked paper) that is being used as the optimization algorithm to fit the sensor observations to the assumed fields. At higher frequencies, this simplification is likely sufficient as there isn't much time for the two to diverge and you can arrive at a reasonable estimate after only one iteration. As you slow down the algorithm this likely isn't the case and you would need to iterate until you get a reasonable error term.
In summary, you can definitely track orientation using a 9DOF MEMS sensor. I'm not clear why you are attempting to run this algorithm as slowly as you are but there are some spots in the algorithm to check if you want to improve the lower bound but be aware that they will come with significant overhead which means that if the reason you are having this issue is because it is the best your hardware is able to achieve (maybe due to other background tasks) then I would recommend offloading background tasks or upgrading hardware to improve your rate rather than trying to tweak the algorithm. Generally speaking, AHRS and IMU systems should be run at the highest rate you possibly can on dedicated hardware as its performance tends to have fairly critical implications for the rest of your system.
Best Answer
I think that you will want to use a combination of sensors. The accelerometers and gyroscopes will be able to correct for strong breezes. You can then use GPS to counter out the longer-term drift (or bias, as it is sometimes called). I think that the combination of these two sensors in some sort of filter (probably a Kalman) will keep your position drift minimized.
GPS won't be accurate enough by itself though. An alternative approach to the Kalman filter (which can get a bit math heavy) is to use the DCM algorithm from DIYdrones. There seems to be a lot of success in using this so far.
Finally, the Parrot drone quadrotor uses a downward-facing 60fps camera to cancel out drift. It looks down and extracts features from the ground under it, then uses a type of visual odometry (I'm assuming some sort of optical flow algorithm) to determine how far the quadrotor has drifted. I believe that this only works at low altitudes on the Parrot, but I see no reason why it couldn't be extended to a higher altitude.