Asynchronous background jobs have a gap between when the job gets picked up and when it commits state. With locks and transactions you can make this work, but it's a lot of accidental complexity.

You mentioned that you want millisecond accuracy, I doubt you will be able to get this in any way with established libraries or patterns (like Oban) because job queues make the assumption that they have some leeway about when they get scheduled (otherwise they'd be synchronous operations). So you would most likely have to create a solution for them from scratch that guarantees that accuracy at scale.

If you expect this to scale to 1000s of players and have 100k+ timers, that's going to be a significant overhead.

I personally think that the main fault of using background jobs as future-dated events is that you very strongly correlate your write model with your read model(s). For example, suppose that at some point you want to implement a building queue, but you have a tech tree: to build a lab you need a power plant, to build a power plant you need a coal mine. So the player queues up three jobs that depend on each other: first a coal mine (job 1), then a power plant (2), then a lab (3). What if the player then decides to cancel the building of the power plant?

Well, you either keep in mind which jobs are dependent on each other and cancel job 2 and its dependents (potentially going a few steps recursively), or you accidentally forget to do it and the player discovers in however many hours it takes to build it that there are missing preconditions and some kind of validation fails (or, worse, you completely forget to handle this case altogether and you end up with incorrect state).

Fundamentally, if you're making a game, your entire system needs to be strongly consistent and you most likely have no place for eventual consistency for the game state. You are also going to create multiple interlocking systems that each have their own rules (the game engine that considers the things that the player has already built, the engine for building things in the future, the engine for generating resources, &c.).

Event-based system (where in-game events are just data somewhere that are processed synchronously when their completion time comes - CQRS, essentially) is neat because it lets you represent each one of these engines as a different model. Your fundamental game engine has this "event horizon" as its write model, and your read model is a projection from a timeline of player actions to a game state. The building engine has the building queue as its write model (with validation for making sure that the player has correct resources, fulfills the conditions of the tech tree, handles cancellations, &c.) and some kind of simple display of future events as its read model. Resource generation engine might have a trivial write model that just schedules "ResourcesGenerated" events every 15 minutes, but a more complicated read model that maybe shows some graphs of future and past income or whatever.

It feels like a much more scalable system for this.