Because the backend of a game where everything has to run in realtime is going to be completely different from a backend where you can expect to perform all the calculations and database work only when the turn (or in this case, time) is incremented?
Not necessarily. It all depends on how it's programmed. Real-time games still operate in 'ticks' or 'turns.' The only real difference is that real-time games tend to have very small 'ticks' (turns) of much less than a second, and continue to advance the ticks at a steady rate unless the user pauses or otherwise speeds/slows the rate at which ticks occur. In Aurora a 'tick' is 5 seconds.
I've never had the chance to look at Aurora's underlying code, but my best guess based on how it's played is that it operates in terms of ticks, where some processes are set to happen every one tick and others (like the production cycle) are set to other lengths. If this is the case, changing the back end to a pausable real-time system (kinda like a Paradox grand strategy game) shouldn't require too terribly much refactoring. If Aurora isn't set up like that, however, then I have no idea.
Another way to do real-time, which would be much harder for Aurora, would be to use an event-based system, where the code is always listening for an event to happen - like "Construction of 5,000 Infrastructure on Earth complete," at which point whatever code is written around that event would fire and run semi-asynchronously while the main body of code continues to listen for more events. This isn't a 'turn' or 'tick' based system, which has its advantages and disadvantages, and as a result I believe would be much more difficult to implement than steadily advancing turns/ticks - assuming that Aurora's code is already set up to handle things in ~5 second increments.
EDIT: Of course, either way is still an assload of work and Steve's time is almost certainly better spent on other aspects of the game at the moment.