You've got to be a LOT more specific to figure out how to make events 'tick' in a web environment. To take your main points:
Players interact with each other.
Spectacular! How? They fight and/or trade, I assume, from the army bit in the next sentence. Do you allow active/inactive fights? If so, all outcomes will be formulaic (pre-determined actions by inactive player). Your game logic will be something like ACTIVE_PLAYER attacks SUPERMAN, SUPERMAN not online (query updates for SUPERMAN, apply), SUPERMAN follows scripted battle.
Fleets and armies are moving around in time. Training occurs in time.
Probably nothing happens during transit/training, right? Or, if it does, those changes are effective after the movement/training? Then all changes can be applied when USER/PLANET/BASE/AREA is accessed after the end time.
It would be far too complex to only compute relevant changes when the user can see it as you'd have to build up some kind of map of all the interactions between the player, the player he's interacting with, all players that player has interacted with etc.
Why is it too complex? A user doesn't need to change AT ALL unless someone (the user himself or another player) accesses the user. When your battle/trade/display scripts access user data, they should confirm the data is timely (typically by including a LAST_ACCESSED field or separate, searchable update queue). You don't need to know (or care) what triggers your update method, you just need it to run prior to any interaction.
I would avoid lumping all your check update routines at login because you'll still want progress to roll forward while users are playing. Especially at the beginning of your dev cycle, no one will be signing in, meaning you'll never have updates while playing.
But really, what is happening EVERY minute? Interest on bank accounts? Auto-experience? Some sort of special power growing? Those are typical things (AFAIK) that can happen "constantly" in a game, but they are often not. Even some of the most complex growth patterns you can find (I did some crazy interest gains in Calc) can be figured in one step to adjust for time. Say you want them to gain 0.5% of their experience every minute and they don't login for exactly one week (10080 minutes). You just use a basic compound interest formula (assume 100 XP at logout 1 week ago - in the Wikipedia link, here n is 1): 100(1+.005)^10080 = 682185533694734340099690.06898055 XP when they login again. Also, that is a prime example of why you should avoid any kind of uncapped interest on games...
The point is that your updates are probably just numbers changing by a formula and you can adjust that formula for ANY amount of time, making "on-demand" updates a simple, practical solution.
Another thing to remember is you AREN'T Farmville or EVE. You aren't trying to balance simultaneous updates of 600,000 users in realtime because you have 500,000 online. Trying to design for those problems when you'll be successful with 10,000 regular players (not simultaneous) is absurd. Do you think about transferring exabytes of data every time you make a website?
Anyway, feel like I'm straying from the initial point: Breakdown EXACTLY what is happening in your game and then figure out how to best keep it up-to-date. That means being much more specific than armies grow, people age; you have to figure out precisely how you will track that information (database design/formula work). I'm not out to dis cron jobs, even this usage, just that you need to consider if that's the best method. The only way you can do that is by knowing precisely what and why your 'update.php' does every minute.