The attached small example file models a simple block. Its center of mass is in the origin of the global coordinate system. The material is linear elastic. There are neither loads nor boundary conditions, just an initial rotational velocity around the global 1-axis.

Running it (from the command line after a rename from .txt to .inp, an import into Abaqus/CAE will not work) takes less than 5 min on a common notebook.

The animation looks as boring as expected. I have used U1 for a contour plot, to check how much round-off errors Abaqus/Standard shows after 30 full rotations (implicit dynamic analysis). No surprise here either, the displacements are in the range of pm (picometer).

Now let the block rotate around the global 2-axis. Since the .inp file is parametrized, you just need to change the last data line of the first *PARAMETER keyword to

  axis = 2

and rerun.

As before the animation looks normal. Also U2 does not show any signs of larger round-off displacements (again picometers only), let alone instabilities.

Finally, set

  axis = 3

in the .inp file and rerun.

The animation now reminds me on

  https://en.wikipedia.org/wiki/Rollin%27_and_Tumblin%27

and looks like this:

Surprised? In what muddy waters (pun fully intended) did the analysis get just by changing the axis? Is Abaqus becoming unstable? Have we found a bug?

No. We have rediscovered the

  https://en.wikipedia.org/wiki/Tennis_racket_theorem

sometimes also named the Dzhanibekov effect, after the Soviet cosmonaut who encountered it during one of the Soyuz missions. Roger Federer, though, has the habit of rotating his racket similar to our first analysis, which gave a stable result, a proper match to his controlled behavior on court. And, finally, the master of us all? Well, this is of course Leonhard Euler as referred to in the quote by https://en.wikiquote.org/wiki/Pierre-Simon_Laplace, himself no fool either.

With Euler's equations it is very easy (and very elegant!) to show that the rotation around the "intermediate axis" (as in our 3rd analysis) is always unstable. When I was taught this by my favorite professor back at university, I became excited for days, even though I knew the effect from rotating  (table) tennis rackets myself. More about the proof can be found in the Wikipedia article, which in all fairness also mentions that the effect was explained first by Louis Poinsot, a French mathematician previously unknown to me, in 1834, much later than Euler.

Now on to the Abaqus side of the problem. The .inp file is not only heavily parametrized, but also the  mesh is created by arcane Abaqus wizardry (so arcane that I had to look up and try a lot of stuff). In case you are not familiar with the parametrization, read

  Abaqus
  Abaqus Introduction & Spatial Modeling
  Parametric Modeling

in the fine documentation. Yes, all of it. And even though I knew this stuff from long years of Abaqus  usage, the *PARAMETER DEPENDENCE option had somehow vanished from my radar, but is now a welcome addition to my repertoire. Try to understand how I employed this feature to be able to change the rotation axis by changing a single byte (instead of the 3 numbers normally required by the *INITIAL CONDITIONS option). However, no need to try to understand the *NGEN, *NFILL, and *ELGEN stuff, unless you are very, very curious.

Let us finally have a look at the numerics in the .sta files. It may suprise you to see how many increments and iterations Abaqus needs for such a seemingly simple problem: After all, it is mostly rigid body rotation. However, a general purpose FEA code (in contrast to special purpose rotordynamics codes)  does not have any prior knowledge about this. So within an iteration, which is the solution of a linear (!) equation system, a rotation amounts to the corners of our block moving tangentially, but in a straight line. This is  similar to the "pumping effect" seen when visualizing torsional modes of an eigenfrequency analysis, a  frequent cause for complaints you may have read here: "My structure is getting bigger! This must be  wrong!". This linearized motion gives rise to element distortion, so the increments have to be small.

But maybe we can help Abaqus, by providing hints about the nature of the problem? You could try, e.g., by setting the EXTRAPOLATION parameter of the *STEP option to a different value (as you know, I normally argue for the default settings).

According to

  Abaqus
  Analysis
  Analysis Procedures
  Introduction
  Defining an Analysis
  Incrementation
  Incrementation in Abaqus/Standard
  Extrapolation of the Solution

the default in our "transient fidelity" implicit dynamic analysis is

  *STEP, EXTRAPOLATION=VELOCITY PARABOLIC

but

Displacement-based parabolic extrapolation uses two previous incremental solutions to obtain the first guess to the current incremental solution. This type of extrapolation is useful in situations when the local variation of the solution with respect to the time scale of the problem is expected to be quadratic, such as the large rotation of structures

sounds promising, so I tried

  *STEP, EXTRAPOLATION=PARABOLIC

instead, but it did not help. Neither did setting the value to LINEAR (the default for other analysis procedures) nor, as expected, setting it to NO. The following table summarizes the findings:

An interesting detail is the last row: Because no extrapolation is done at all, Abaqus needs more  iterations per increment on average. This resulted in much fewer tries to increase the time increment and also much fewer failed attempts (i. e., cutbacks). But in total the number of iterations (which determines the CPU time) is still highest.

The bottom line: Stick with the defaults. And do it like Federer.