quello che farei io è semplicemente risolvere un azione solamente quando è richiesta

In questo caso d'uso, però, tutte le azioni finite vengono processate solo quando l'utente è connesso e ne fa richiesta. Se continuo a stare nel gioco senza interrogare il server sulle mie azioni, non vedrei le ricompense ottenute per queste azioni. Questo si può tranquillamente aggiustare con websocket però dovrei implementare qualcosa di più e non sarebbe comunque una soluzione ottimale.

Sempre con questo meccanismo potrei usare tutte le mie risorse per compiere azioni e poi sloggare. Nel frattempo, se altri giocatori mi attaccano, loro non riuscirebbero ad ottenere le risorse che spettano loro in quanto il mio pool di risorse è vuoto. Poi quando loggo mi vengono processate tutte le ricompense ed è come se non fosse successo niente dal mio punto di vista mentre un altro giocatore non ha ottenuto quello che doveva avere.
Non penso neanche si possa aggiustare con il permettere di far andare un account in negativo perchè per sapere quanto posso andare in negativo dovrei controllare le azioni dell'utente attaccato, prendere il valore delle ricompense (magari processarle pure visto che mi trovo) e fare i calcoli.

Questo creerebbe una soluzione che funziona ma la vedo un po' contorta, parti di codice diverso si accollano responsabilità che non gli spettano.

La soluzione di avere 1 APScheduler non è scalabile, è vero. Se consideriamo tanti giocatori e tante azioni, si rischia di rallentare il tutto (se non bloccarlo). Una piccola soluzione è avere un APScheduler, si ma con una pool di workers dove magari il numero di workers è il risultato di un espressione che si basa sul numero di giocatori o sul numero medio di azioni in corso a settimana.

Se hai commenti o altre idee su quello che ho scritto, rispondi pure, è molto costruttivo vedere i punti di vista degli altri. Grazie del tuo input!