I worked on a U.S. Naval Reserve Personnel machine that had to be up pretty much no matter what you did to it. But that is not consistent with any normal operating system. Windows, UNIX, OpenVMS, and a few others reach a moment where you ABSOLUTELY POSITIVELY must drop the system to allow for garbage collection and reclamation. Access "bloat" (the phenomenon where the files grow in size) is one example of the garbage collection problem. Call it a cost of doing business. Even during Operation Desert Shield and later Desert Storm, our systems had built-in down time to allow reboots and restarts.
My weekly down time for my Access security-related operations tracking was that we got everyone to agree on a time that the DB could go down with minimum impact. Oddly, because of night-shift operations being busy due to things happening in other time zones, we picked Noon on Fridays. When I took my systems down, the BE would get backed up, then Compressed & Repaired. If there was a new FE pending for release, I would stage that as well. I had one hour to get everything done. As long as I was assiduous in my testing leading up to the maintenance hour, it was not a problem.
Part of the problem is that both Windows and Access (both Microsoft products) use similar memory allocation and reclamation methods, which are inherently imperfect. What causes the bloat is that when you take out a chunk of memory as a scratchpad in which to work, and something else then does the same thing to an adjacent piece of memory, the release process can be unable to re-merge the released memory chunks, so these disconnected and unusable chunks slowly build up.
For Windows, what happens is that either Windows itself or some program just crashes if you waited too long to reboot and the system scratchpad gets depleted. I.e. you don't get a choice. Though I must say that Win10 is FAR better at longevity than Win6 or Win7 ever were. And let's not even talk about earlier versions, OK? The memories are too painful.
For Access, the bloat keeps going until you deplete system virtual memory because too much of the DB is bloat and it clogs up the Virtual Memory (SWAP & PAGE) file. There, a reboot doesn't help. You need to run the Compact & Repair to force proper memory reclamation. You have yourself documented in your request just how much bloat you reclaim.
What can I do to keep it running fast and small sized?
It is the nature of the beast that you cannot unless you can do away with DELETE and UPDATE operations altogether. But even then, SELECT queries use some scratchpad memory to organize the records to be returned, which would lead to eventual bloating - just not as often and not as bad.
Even the "Big Boys" need down time to do things like optimize indexes and reallocate data bucket loads. Those were ORACLE terms but the concept is similar for other vendors like SQL Server, SYBASE, INFORMIX, and (now defunct) ShareBase. It's a fact of life that running software gets "dirty" and needs periodic maintenance. If you don't build that into your schedule and MAKE IT STICK, you will have a crashed and unrecoverable database on your hands.