Having played with both versions, I've actually end up agreeing with your theory, and forcing more frequent garbage collection might well be the simplest solution. (To be fair, the crash will probably still happen if a level manages to actually, truly use up more video memory than available, but at least much harder now that we're cleaning up more aggressively.)
I am able to get an assert (attached) pretty easily in the 0.2.32 version in above post, after repeated forward and rewind. OKing past the assert then led right to some sort of memory exception. It doesn't bring up a callstack with mentions of joystick, but presumably it was the same underlying issue. More tellingly, I had set Window's Task Manager to be "Always on Top" to monitor Lix's memory usage while it is running (I guess you could also probably just run Lix in windowed mode), and indeed it shows Lix rather quickly balloons to well over 1 GB memory usage in forward/rewind scenarios especially when I kept the rewind key held down.
With version 0.2.33's garbage collection, memory usage stays at around 360 MB with no rapid runaway memory consumption according to Task Manager, even with repeated forward and rewind, and accordingly I've yet to cause the issue to happen. (There is still some minor growth in memory usage over time, but far, far more gradual and may well be expected as part of managing savestates for rewinds.) I didn't notice much difference performance-wise; if anything I think 0.2.33 is slightly better perf-wise during rewind, probably due to keeping the memory usage more in check compared to v0.2.32.
Forcing GC may be a "hack" in one sense, but in this case, your theory seems correct based on evidence, and unless you rewrite code to get much more explicit in managing the lifetimes of objects owning Allegro bitmaps (sounds prone to mistakes creating other kinds of bugs), forcing GC is at least the safest way to handle this.