Background
Let’s have a brief look at what parameters an integrator typically has and what they are used for. All of them govern step-size adaption:
Relative tolerance (rtol) is usually the most important parameter governing accuracy. After an integration step, the integrator estimates the magnitude of the error it makes and if it exceeds the relative tolerance, a smaller step is taken instead. Values between $10^{-5}$ and $10^{-3}$ are typical. If you have any way to estimate which relative error would affect your analysis, a few orders of magnitude below this is a good choice. However, usually it’s just how accurate you want your integration to be. Since this value is relative, nondimensionalisation should not affect it.
Absolute tolerance (atol) is like relative tolerance, just going by absolute values. It is conventionally cumulative with absolute tolerance, i.e., the error needs to be below atol+rtol*state. Unless you set it to a high value or atol to zero, it becomes only relevant if a dynamical variable crosses zero, as relative tolerance cannot cover this well.
Most integrators have other parameters like the maximum and minimum step size, the initial step size and further parameters governing the step-size adaption.
Why nondimensionalise?
For a normal integrator, the default values of these parameters are made for a setup where all your dynamical variables have the same order of magnitude, that order of magnitude is 1, and the smallest time scale of your dynamics also has an order of magnitude of 1.
If this does not apply, you have to consider all integration parameters (not just the tolerances) as to whether they need to be adjusted.
For many integrators, you also have the problem that you cannot set the absolute tolerance per component.
Unless you know what you are doing and can set all the parameters accordingly, it’s easier and safer to nondimensionalise.
Possible consequences of badly set integration parameters include a failing integration, bogus results, and an overly slow integration.
Your specific case
Some thoughts on your specific scenario:
Your time scales are very high. I would have to look into the details of the integrators you used, but it might very well be that you barely made use of the adaptive integration, and instead progressed with the default maximum time step (which in turn is still very small compared to the time scale of your dynamics) and thus wasted computation time.
Your absolute error was probably be too low. If your dynamical variables never become zero, it is not surprising if this had no effect. You may also just have been lucky. In general, if you have zero crossings and you have dynamical variables of different orders of magnitude, you cannot have an absolute error that is appropriate for all of them (see above).
Your relative error is okay.
If your dynamics varies on several orders of magnitude, consider performing the entire integration in the logarithmic domain.
Digression: Why can’t the integrator do this?
Adapted from this answer of mine
You might ask yourself: Can these parameters not be chosen more dynamically? As a developer and maintainer of an integration module, I would roughly expect that introducing such automatisms has the following consequences:
- About twenty in a thousand users will be spared from problems arising from overly large or small dynamical variables or time scales.
- About fifty in a thousand users (including the above) miss an opportunity to learn some fundamentals about how integrators work and reading documentations.
- About one in thousand users will run into a horrible problem with the new automatisms that is much more difficult to solve than the above.
- I need to introduce new parameters governing the automatisms that are even harder to grasp for the average user.
- I spend a lot of time in devising and implementing the automatisms.
